Metabase高危漏洞CVE-2021-41277复现：未授权文件读取原理与防御

1. 项目概述：一次对Metabase文件读取漏洞的深度剖析

最近在整理内部安全资产时，又回顾了Metabase这个老牌开源BI工具在2021年底爆出的一个高危漏洞——CVE-2021-41277。这个漏洞的本质是一个未授权文件读取，攻击者无需任何认证，就能通过构造特定的API请求，读取服务器上的任意文件。听起来是不是有点吓人？对于一个通常存放着大量数据库连接信息、仪表板配置甚至可能包含密钥的BI平台来说，这无异于把后门钥匙放在了门口脚垫下面。

我之所以想把这个漏洞的复现过程详细写出来，并不是鼓励大家去做坏事，恰恰相反。对于安全工程师和运维人员来说，理解漏洞的原理、亲手复现一遍攻击链，是构建有效防御体系最扎实的一步。只有你知道攻击者是怎么进来的，你才知道该把哪扇门焊死，该在哪个路口设置检查站。这个漏洞的复现过程清晰、典型，非常适合作为Web应用安全学习的案例。它不涉及复杂的二进制利用，核心在于对应用程序路由和参数处理的深入理解，非常适合有一定Web基础、想切入安全领域的朋友，或者正在负责Metabase运维的同行参考自查。

简单来说，通过复现CVE-2021-41277，你将能清晰地看到：一个设计上的小疏忽（对用户输入路径的校验不足）如何被放大成一个严重的安全问题；如何一步步从公开的漏洞描述，定位到具体的代码差异，并最终构造出可用的攻击载荷（Payload）。整个过程就像一次完整的安全诊断，从“知其然”到“知其所以然”。

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

2.1 漏洞核心：API路由与路径穿越

CVE-2021-41277的根源在于Metabase的/api/geojson接口。这个接口的本意是让管理员上传自定义的GeoJSON地图文件，用于在地图可视化组件中展示更丰富的地理信息。在漏洞版本（v0.40.5及之前，以及v1.40.0之前的版本）中，该接口的实现存在缺陷。

关键问题出在参数处理上。接口大概是这样设计的：GET /api/geojson?url=file:///path/to/your/file.json。开发者的初衷可能是允许通过url参数指定一个服务器本地文件系统路径（file://协议）或远程HTTP地址来加载GeoJSON。然而，在拼接或解析这个url参数时，Metabase没有对用户传入的路径进行严格的标准化和校验，导致经典的“路径穿越”（Path Traversal）攻击成为可能。

路径穿越，也常被称为目录遍历，其核心是利用../这样的序列来“向上”跳出程序预期的目录范围。例如，如果程序预期读取/var/www/metabase/geo/下的文件，但攻击者传入url=file:///etc/passwd，甚至url=file:///../../../../etc/passwd，脆弱的路径处理逻辑就可能被欺骗，最终访问到系统敏感文件。

在Metabase的案例中，攻击者可以完全绕过认证，直接向/api/geojson接口发送请求。由于缺乏对file://协议路径的有效过滤和限制，攻击者便能读取服务器上的任意文件，包括但不限于：

• 系统文件：/etc/passwd（用户账户信息）、/etc/shadow（密码哈希，需root权限）、/proc/self/environ（进程环境变量，可能泄露密钥）。
• Metabase配置文件：/metabase-data/metabase.db（H2嵌入式数据库，默认存储所有配置、用户、查询历史），./metabase.yml（应用配置文件，可能含数据库密码、邮箱密码等）。
• SSH密钥：/home/<user>/.ssh/id_rsa。
• 云服务凭证：例如AWS的~/.aws/credentials。

注意：实际利用中，能否读取到某些文件还受到服务器进程运行权限（如Docker容器内部用户权限）的限制。但读取应用自身的数据库和配置文件，成功率极高，危害巨大。

2.2 影响版本与修复方案

根据官方公告，受影响的Metabase版本非常广泛：

• Metabase 开源版本 v0.40.5 及之前的所有版本。
• Metabase 企业版本 v1.40.0 之前的所有版本。

这意味着在2021年10月修复之前部署的绝大多数Metabase实例，如果暴露在公网或内网不可信环境中，都处于风险之中。

官方的修复方案非常直接：在v0.40.6和v1.40.0版本中，彻底移除了/api/geojson接口通过file://协议读取本地文件的功能。现在该接口只允许通过HTTP/HTTPS协议从可信的远程URL加载GeoJSON资源。这相当于直接堵死了利用本地文件系统路径进行攻击的通道。对于运维人员而言，最紧急且有效的应对措施就是立即将Metabase升级到修复版本。

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

“纸上得来终觉浅，绝知此事要躬行。” 要真正理解这个漏洞，最好的办法就是在一个安全的、隔离的环境里亲手复现它。下面我会详细说明搭建靶场环境的每一步。

3.1 使用Docker快速部署漏洞版本

Docker是搭建漏洞复现环境的神器，它能提供完美的隔离性，避免对宿主机造成任何影响。我们选择部署存在漏洞的metabase/metabase:v0.40.5镜像。

首先，确保你的系统已经安装了Docker和Docker Compose。然后，创建一个简单的docker-compose.yml文件来定义我们的服务：

version: '3.8' services: metabase-vulnerable: image: metabase/metabase:v0.40.5 container_name: metabase-cve-2021-41277 ports: - "3000:3000" environment: MB_DB_TYPE: h2 MB_DB_FILE: /metabase-data/metabase.db MB_JETTY_HOST: 0.0.0.0 volumes: - ./metabase-data:/metabase-data

对配置的几点解释：

1. image: 指定了含有漏洞的特定版本镜像。
2. ports: 将容器内的3000端口映射到宿主机的3000端口，这样我们就能通过http://localhost:3000访问Metabase。
3. environment:
   • MB_DB_TYPE: h2： 使用H2嵌入式数据库，这是Metabase的默认配置，方便快捷。
   • MB_DB_FILE: 指定H2数据库文件的路径。注意，这个文件将是我们的主要攻击目标之一。
   • MB_JETTY_HOST: 0.0.0.0: 让Metabase监听所有网络接口。
4. volumes: 将宿主机的./metabase-data目录挂载到容器的/metabase-data路径。这样做有两个好处：一是数据持久化，容器删除后数据还在；二是方便我们后续验证攻击结果，因为我们可以直接在宿主机上查看被读取的数据库文件内容。

在包含docker-compose.yml文件的目录下，执行启动命令：

docker-compose up -d

-d参数表示在后台运行。使用docker-compose logs -f可以查看实时日志，当你看到类似“Metabase Initialization COMPLETE”的日志时，说明服务已经启动成功。打开浏览器访问http://localhost:3000，按照界面提示完成Metabase的初始设置（创建管理员账户等）。这一步是必要的，因为它会生成我们后续要窃取的数据库文件。

3.2 攻击工具选择：Curl与Burp Suite

对于这个漏洞的利用，我们不需要复杂的工具，一个能发送HTTP请求的工具即可。

• Curl（命令行）： 轻量、直接，适合快速测试和脚本化操作。我们将主要使用它来演示攻击请求。
• Burp Suite（图形化）： 功能强大的Web安全测试平台。它的Proxy（代理）和Repeater（重放）功能非常适合手动测试、修改和观察HTTP请求与响应。对于初学者，我强烈建议使用Burp Suite Community Edition（免费版），它能让你更直观地理解整个交互过程。

Burp Suite基础配置：

1. 启动Burp Suite，在Proxy -> Options中，确保代理监听在如127.0.0.1:8080。
2. 将浏览器（如Chrome）的代理设置为127.0.0.1:8080，并安装Burp Suite的CA证书（首次使用时Burp会提示）以拦截HTTPS流量。
3. 访问http://localhost:3000，你将在Burp的Proxy -> Intercept标签页中看到所有经过的请求。可以点击“Intercept is on”按钮将其关闭，让流量正常通过，然后在HTTP history中查看记录。

环境就绪，工具在手，接下来就是最关键的环节：发起攻击并解读结果。

4. 漏洞利用实操：步步为营获取敏感信息

现在，让我们扮演一次攻击者（在合法的靶场环境中），尝试利用这个漏洞。我们的目标很明确：在不提供任何用户名密码的情况下，读取Metabase服务器的敏感文件。

4.1 构造并发送恶意请求

漏洞利用的入口点是/api/geojson接口，参数是url。我们首先尝试读取一个经典的Unix系统文件/etc/passwd，来验证漏洞是否存在。

使用Curl发送请求：

curl -v "http://localhost:3000/api/geojson?url=file:///etc/passwd"

• -v： 参数表示显示详细输出，包括请求头和响应头，方便调试。
• 请求的URL： 直接指向我们靶场的Metabase，参数url的值是file:///etc/passwd。

如果漏洞存在，你应该会收到一个HTTP 200响应，但响应体内容可能不是/etc/passwd的内容，而是一个JSON格式的错误信息，提示文件不是有效的GeoJSON。这恰恰是漏洞利用成功的标志之一！因为接口试图解析目标文件为GeoJSON，解析失败则返回错误，但错误信息中可能包含文件的内容片段。不过，更可靠的方法是读取文本文件。

让我们读取一个肯定是文本格式的文件，比如Metabase自身的配置文件（如果存在）或一个我们已知的文本文件。在Docker容器内，我们可以尝试读取/proc/self/environ，这个文件包含了当前进程（即Metabase）的所有环境变量，信息量巨大。

curl -s "http://localhost:3000/api/geojson?url=file:///proc/self/environ" | head -c 500

• -s： 静默模式，不显示进度或错误信息。
• head -c 500： 只显示回显的前500个字符，避免终端被刷屏。

如果成功，你可能会看到一长串以\x00分隔的环境变量键值对，其中就可能包含MB_DB_FILE、MB_JETTY_HOST等我们在docker-compose.yml里设置的值，甚至可能有其他敏感信息。

4.2 定位并窃取核心数据库文件

读取系统文件证明了漏洞的存在，但对攻击者而言，真正的“宝藏”是Metabase的数据库文件。根据我们启动容器时的配置，数据库文件位于/metabase-data/metabase.db。这就是我们挂载到宿主机./metabase-data目录下的那个文件。

现在，我们直接读取它：

curl -s "http://localhost:3000/api/geojson?url=file:///metabase-data/metabase.db" | head -c 200

这次，你很可能看不到任何可读的文本输出，或者输出是乱码。这是因为metabase.db是一个二进制的H2数据库文件。接口尝试把它当作文本（GeoJSON）来解析，自然会失败，响应体可能是空的或者包含解析错误信息，但文件内容已经通过请求被读取了。在真实的攻击中，攻击者会如何获取这个二进制文件呢？

他们通常会将文件内容进行编码（如Base64），或者利用其他技巧使其“通过”接口的响应返回。一个更简单直接的方法是使用路径穿越，尝试读取数据库文件的“日志”或“备份”文本版本（如果存在），但更通用的方法是：利用漏洞将文件内容输出到错误信息或通过其他间接方式获取。对于复现学习，我们可以换一个思路：读取数据库的SQL脚本备份（如果存在），或者，更重要的是，证明我们可以读取应用目录下的任何文件。

我们可以尝试读取Metabase的配置文件模板或已知的文本资源文件。但为了教学目的，我们直接验证对数据库文件路径的访问能力。虽然curl直接显示乱码，但我们可以用od（八进制转储）或xxd（十六进制转储）命令来验证返回的是否是二进制数据，或者将输出重定向到文件：

curl -s -o downloaded.db "http://localhost:3000/api/geojson?url=file:///metabase-data/metabase.db" file downloaded.db

• -o downloaded.db： 将响应体保存到名为downloaded.db的文件中。
• file downloaded.db： 用file命令判断下载文件的类型。

如果file命令显示它是data或类似信息，或者明确说是SQLite 3.x database（H2在某些模式下与SQLite格式兼容），那么恭喜，你已经成功“窃取”了数据库文件。在宿主机上，你可以用sqlite3命令（因为H2的嵌入式文件格式与SQLite兼容）或专门的H2数据库工具来打开这个downloaded.db文件，查询其中的core_user表（用户表，含密码哈希）、report_dashboard表（仪表板）、report_card表（问题/查询）等，所有元数据一览无余。

4.3 使用Burp Suite进行精细化测试

图形化工具能让我们更细致地观察和操作。打开Burp Suite，确保代理已开启且浏览器配置正确。

1. 拦截请求：在Burp的Proxy -> Intercept标签页，打开拦截（Intercept is on）。
2. 触发请求：在浏览器中访问http://localhost:3000/api/geojson?url=file:///etc/passwd。
3. 查看与重放：请求会被Burp拦截。你可以在这里直接查看原始的GET请求。点击“Forward”放行，然后在Proxy -> HTTP history中找到这条请求记录。右键点击该请求，选择“Send to Repeater”。
4. 在Repeater中操作：切换到Repeater标签页，你可以看到完整的请求。点击“Send”发送，右侧会显示服务器的响应。你可以随意修改url参数的值（例如改成file:///metabase-data/metabase.db，或尝试路径穿越如file:///../../../../etc/passwd），每次修改后点击“Send”观察响应变化。通过查看响应的大小（Response length）、状态码和内容，可以判断文件是否存在、是否可读。

Burp Suite的另一个强大功能是Intruder，它可以用于自动化测试，比如批量尝试读取一系列常见的敏感文件路径（如/etc/shadow,/root/.bash_history,~/.ssh/id_rsa等）。这对于全面的信息收集非常有效。

5. 漏洞根因分析与代码审计视角

复现了攻击，我们再来深入看看“为什么”。这需要一点代码审计的视角。Metabase是开源项目，我们可以直接对比漏洞版本和修复版本的代码差异。

问题的核心文件是src/metabase/api/geojson.clj（Clojure语言编写）。在修复提交中，我们可以看到关键的改动：

1. 移除file://处理逻辑： 旧代码中可能包含了对url参数中以file://开头的字符串的处理，直接将其作为本地文件路径打开。修复后，这部分逻辑被删除或替换。
2. 增加协议白名单： 修复后的代码很可能只允许http://或https://开头的URL，并对允许的域名或URL格式做了更严格的校验。
3. 输入验证与规范化： 可能增加了对输入路径的规范化处理，移除../等危险序列，或者将路径解析限制在某个安全目录内。

从漏洞中我们能学到什么？

• 永远不要信任用户输入： 这是安全开发的第一铁律。任何来自外部的参数都必须经过严格的验证、过滤和规范化。
• 最小权限原则： 应用程序进程不应该有权限读取超出其功能需要的文件。在容器化部署中，可以通过只读挂载、非root用户运行等方式限制。
• 禁用不必要的功能： 如果/api/geojson的file://协议支持不是广泛需要的功能，那么默认禁用它或将其设为高级管理员选项，能显著减少攻击面。
• 安全的默认配置： 像Metabase这样的工具，默认配置应该尽可能安全。在后续版本中，官方直接移除了危险功能，这就是一个正确的做法。

6. 防御措施与安全加固建议

复现漏洞是为了更好地防御。如果你的环境中还有未升级的Metabase，或者你想从这次事件中汲取经验加固其他应用，以下措施至关重要：

1. 立即升级： 这是治本之策。将所有Metabase实例升级到v0.40.6或v1.40.0及以上版本。
2. 网络层面隔离：
   • 绝不暴露在公网： Metabase这类后台管理、数据分析平台，除非绝对必要，否则不应直接对互联网开放。应通过VPN、零信任网络或跳板机进行访问。
   • 使用反向代理： 即使在内网，也建议使用Nginx/Apache作为反向代理。可以在代理层设置严格的访问控制列表（ACL），例如只允许特定IP段访问/api/geojson接口，或者直接在该位置返回403错误。

   # Nginx 示例配置，禁止直接访问 geojson 接口 location /api/geojson { deny all; return 403; }

3. 容器安全加固：
   • 使用非root用户运行： 在Dockerfile或docker-compose.yml中指定user: 1000:1000（非root的UID/GID），降低权限。
   • 文件系统只读： 对于不需要写入的目录，以只读模式挂载。例如，Metabase的程序文件目录可以设置为只读。

   volumes: - ./metabase-data:/metabase-data:rw - /app/metabase:/app:ro # 假设程序文件在/app下

   • 使用安全基线镜像： 选择Alpine等更精简的基础镜像，减少潜在漏洞。
4. 应用层防护（WAF）： 部署Web应用防火墙（WAF），可以配置规则来拦截含有file://协议、../路径穿越序列的恶意请求。虽然WAF可能被绕过，但能增加攻击门槛。
5. 定期安全扫描与审计： 对自研或使用的开源组件，定期进行漏洞扫描（如使用Trivy扫描容器镜像，使用Dependency-Check检查项目依赖）和代码安全审计（特别是处理用户输入、文件操作、网络请求的代码段）。

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

在复现过程中，你可能会遇到一些“坑”，这里记录下我踩过的和可能遇到的问题：

1. 请求返回400或500错误，而不是文件内容：

   • 检查Metabase版本： 确保你拉取的是正确的漏洞版本镜像（如v0.40.5），而不是最新的已修复版本。用docker images确认。
   • 检查接口路径： 确认路径是/api/geojson，不是/api/geo-json或其他变体。查看对应版本的开源代码或API文档是最准确的方法。
   • 检查参数格式： 确保是url参数，并且值以file://开头，路径是绝对路径（如file:///etc/passwd）。在Burp中检查请求格式是否完全正确，没有多余的字符或编码问题。

2. 读取数据库文件得到乱码或空响应：

   • 这是正常现象： 如前所述，接口期望GeoJSON文本，二进制文件会导致解析失败。重点检查响应头中的Content-Length是否大于0，或者将响应体保存为文件后用file或hexdump命令检查，这通常意味着文件内容已被读取并包含在响应流中（尽管可能被包装在错误信息里）。
   • 尝试其他文件： 先读取/etc/passwd或/proc/self/environ这类肯定可读的文本文件，确认漏洞利用链是通的。

3. Docker容器内文件路径问题：

   • 容器内视角： 你的攻击请求是针对容器内Metabase进程的。因此，file:///etc/passwd指的是容器内的/etc/passwd文件，不是宿主机的。要读取挂载卷的文件，需要使用容器内的路径（如我们设置的/metabase-data/metabase.db）。
   • 权限问题： 即使路径正确，如果Metabase进程用户（在早期版本可能是root，后期改为非root）没有读取该文件的权限，也会失败。可以通过docker exec -it metabase-cve-2021-41277 /bin/bash进入容器，尝试cat /etc/passwd来验证权限。

4. Burp Suite拦截不到流量：

   • 检查代理设置： 确保浏览器代理配置指向Burp（如127.0.0.1:8080）。
   • 检查拦截状态： Burp Proxy的Intercept标签页是否处于“Intercept is on”状态？如果是off，则不会暂停请求，但历史记录中仍应有记录。
   • HTTPS问题： 如果目标是HTTPS，需要在浏览器中安装并信任Burp Suite的CA证书，否则会被浏览器警告拦截。

5. 漏洞利用成功但拿不到有价值信息：

   • 信息收集是关键： 在真实渗透测试中，攻击者会系统性地尝试读取一系列常见敏感路径。可以编写一个简单的Shell脚本或使用Burp Intruder，加载一个包含常见Linux/Windows敏感文件路径的字典进行模糊测试（Fuzzing）。
   • 关注错误信息： 有时文件内容不会直接显示在成功响应里，而是出现在错误信息的细节中。仔细查看响应的每一个角落。

亲手复现CVE-2021-41277这个漏洞，就像完成了一次精细的外科手术，让你清晰地看到了从外部参数输入到内部文件系统访问的完整攻击路径。对于防御者而言，这种体验是无价的。它时刻提醒我们，安全是一个整体，任何一个细微的疏忽都可能成为整个系统防线的突破口。保持对第三方组件的版本关注，建立常态化的安全评估流程，并将最小权限原则贯彻到系统设计的每一个环节，才是应对层出不穷的安全挑战的稳固基石。