从一次内部红队演练说起：我们是如何利用Nacos默认配置拿下集群权限的

从一次内部红队演练看Nacos安全攻防实战

那是一个普通的周二下午，我们红队接到任务：对集团新上线的微服务架构进行渗透测试。作为攻击方，我们没有任何内部权限，只能从公开入口开始探测。谁也没想到，这次看似平常的演练，最终演变成了一场关于Nacos安全配置的深刻教训。

1. 初始侦察：发现暴露的Nacos控制台

通过子域名扫描工具，我们很快发现了一个有趣的地址：nacos.internal.example.com。访问后跳转到一个登录页面，经典的Nacos控制台界面。尝试用最常见的默认凭证：

用户名：nacos 密码：nacos

令人惊讶的是，系统竟然直接放行了——第一个安全防线就这样被突破。登录后可以看到完整的服务列表、配置中心和命名空间信息。这相当于拿到了整个微服务架构的"地图"。

注意：Nacos从2.2.0版本开始已强制要求修改默认密码，但许多企业升级时并未严格执行此规定。

2. 权限提升：利用JWT密钥漏洞

虽然进入了控制台，但我们的目标是获取集群控制权。检查系统信息发现这是Nacos 1.4.0版本，存在几个关键漏洞：

1. 默认Token密钥：nacos.core.auth.default.token.secret.key仍为初始值
2. UA白名单：nacos.core.auth.enable.userAgentAuthWhite=true
3. 未启用服务身份验证：缺少server.identity配置

使用已知的默认密钥，我们可以构造管理员Token：

import jwt token = jwt.encode( {"sub": "nacos", "exp": 9999999999}, "SecretKey012345678901234567890123456789012345678901234567890123456789", algorithm="HS256" ) print(token)

将这个Token添加到请求头后，我们获得了完整的API访问权限。

3. 集群接管：绕过服务间鉴权

真正的突破来自对集群通信的利用。在1.4.1之前的版本，Nacos服务节点间通过User-Agent验证身份：

GET /nacos/v1/ns/service/list HTTP/1.1 Host: nacos-node1:8848 User-Agent: Nacos-Server

我们简单修改请求头后，集群节点就将我们的请求视为"可信内部通信"，完全绕过了鉴权系统。通过这个漏洞，可以：

• 修改服务路由规则
• 注入恶意配置
• 甚至直接关闭集群节点

4. 防御加固：企业级Nacos安全配置

这次演练暴露出的安全问题，可以通过以下措施有效防御：

4.1 基础安全配置

4.2 网络层防护

• 限制Nacos控制台的公网访问
• 集群节点间通信使用专用网络
• 对7848端口(JRaft通信)实施IP白名单

4.3 运维最佳实践

1. 版本升级：立即升级到2.2.3以上版本
2. 凭证管理：
   • 禁用默认账号
   • 启用LDAP集成
3. 审计日志：监控敏感操作如：
   • 配置修改
   • 服务上下线
   • 用户权限变更

5. 漏洞链的启示：安全是一个体系

这次渗透最值得反思的是，看似独立的小漏洞如何形成致命攻击链：

1. 默认凭证 → 控制台访问
2. 固定JWT密钥 → API权限提升
3. UA验证缺陷 → 集群控制
4. JRaft未隔离 → 主机沦陷

每个环节单独看都不算高危，但组合起来却足以摧毁整个微服务体系。这也印证了安全领域的一个基本原则：防御强度取决于最薄弱的一环。