Nacos未授权访问漏洞CVE-2021-29441：原理、复现与立体防御指南

1. 项目概述：从一次内部安全扫描告警说起

那天下午，我正在梳理微服务链路追踪的日志，突然收到安全团队发来的一封加急邮件，标题赫然写着“生产环境Nacos控制台疑似存在未授权访问风险”。我心里咯噔一下，Nacos作为我们所有微服务的配置中心和命名服务，一旦被未授权访问，意味着攻击者可以窥探甚至篡改数据库连接串、消息队列地址、第三方API密钥等核心配置，这无异于把整个系统的后门钥匙拱手让人。我们紧急排查，发现涉事的正是那个经典的CVE-2021-29441漏洞。虽然官方早已发布补丁，但因为在某些历史版本或特定配置下，这个漏洞依然可能被忽略或错误配置而重现。这次事件促使我决定，不仅要把复现过程记录下来，更要把防御的逻辑和实战中容易踩的坑讲透，这不仅仅是修复一个CVE编号，更是构建服务治理组件安全基线的重要一环。

CVE-2021-29441本质上是Nacos在特定版本（主要影响1.x和2.0.0-2.0.3）中，对其控制台（管理UI）和API接口的访问控制存在缺陷。默认情况下，如果部署时未显式启用认证（nacos.core.auth.enabled=true），或者即使启用了认证但存在配置疏漏，攻击者无需任何用户名密码即可直接访问管理页面，进行命名空间（Namespace）、配置（Configuration）、服务（Service）的增删改查。对于企业来说，这直接导致了敏感信息泄露和业务配置被恶意篡改的双重风险。本文将从一个安全研究兼运维的角度，带你完整走通漏洞的复现、原理分析、利用方式，并给出从代码、配置到架构层面的立体防御指南，目标是让你不仅能“照葫芦画瓢”完成复现，更能深刻理解其背后的安全逻辑，从而举一反三，加固你的整个服务网格。

2. 漏洞原理深度剖析：认证链路上的“失守点”

要理解CVE-2021-29441，我们不能只停留在“没开认证”这个表面原因，而需要深入到Nacos的认证授权流程中，看看防线究竟是在哪个环节被绕过的。这有助于我们在其他类似组件（如Redis、Kibana的未授权访问）中建立通用的排查思路。

2.1 Nacos的认证体系与默认配置的“陷阱”

Nacos的认证功能并非强制开启，这是一个基于灵活性考虑的设计选择，但也成为了安全风险的源头。其核心开关是nacos.core.auth.enabled这个配置项。在1.x和2.x的早期版本中，很多快速启动的教程、甚至是部分官方文档的示例，都直接使用了默认的standalone模式启动，而这个模式下，该值默认为false。

这里存在一个关键的认知误区：很多开发者认为，只要不对外暴露Nacos服务器的8848端口，部署在内网就是安全的。然而，内网安全假设正在被“横向移动”攻击策略所打破。一旦攻击者通过其他方式（如某个Web应用的RCE漏洞）进入内网，这个未设防的Nacos控制台就成了一个绝佳的跳板和情报中心。

认证流程的简化模型是这样的：当用户访问一个需要权限的接口（如/nacos/v1/cs/configs）时，Nacos的过滤器链会检查请求中是否包含有效的身份令牌（如JWT）。如果认证未启用，则这个检查逻辑会被短路（bypass），请求会直接放行。漏洞就源于这个“短路”逻辑的判断不够严密，或者相关的安全过滤器没有被正确注册到所有需要保护的路径上。

2.2 未授权访问的具体路径与影响范围

攻击者无需认证即可访问的路径主要分为两大类，其危害程度也逐级递增：

1. 信息泄露类接口：

   • 服务发现接口：/nacos/v1/ns/service/list。可以列出注册到Nacos上的所有服务实例及其元数据（IP、端口、健康状态）。这相当于给攻击者提供了一张完整的系统架构图。
   • 配置读取接口：/nacos/v1/cs/configs。通过指定dataId和group，可以直接获取应用的配置文件内容。数据库密码、Redis密码、OSS密钥等敏感信息唾手可得。
   • 命名空间列表：/nacos/v1/console/namespaces。获取所有命名空间信息，为后续深入攻击划定范围。

2. 权限提升与篡改类接口：

   • 配置发布/修改接口：同样是/nacos/v1/cs/configs，但使用POST、PUT或DELETE方法。攻击者可以修改现有配置，比如将数据库连接指向一个恶意服务器，从而窃取或污染生产数据。
   • 服务注册/注销接口：/nacos/v1/ns/instance。攻击者可以伪造一个恶意服务实例注册到Nacos，使消费该服务的流量被劫持到攻击者控制的服务器上，实现中间人攻击。
   • 用户管理接口（在特定条件下）：如果开启了认证但未授权访问用户列表接口，攻击者可能枚举用户名，甚至利用其他漏洞进行撞库。

注意：并非所有Nacos接口都受此漏洞影响。一些核心的健康检查、基础信息接口本身是无认证的。关键在于那些本应受控的管理和业务接口被错误地暴露了。

2.3 与同类漏洞的横向对比

理解这个漏洞，可以将其放入“未授权访问”这个更大的漏洞家族中看。比如Redis未授权访问，是因为Redis默认监听所有接口且无密码，攻击者可直接连接执行命令。Elasticsearch/Kibana未授权访问也类似，默认配置下HTTP API无需认证。它们的共性是：默认安装配置以易用性优先，牺牲了安全性，且管理员的安全意识未及时跟上。Nacos CVE-2021-29441正是这一模式在云原生配置中心领域的典型体现。防御思路也相通：最小化暴露面、强制认证、网络隔离、定期审计。

3. 漏洞环境搭建与复现实操

纸上得来终觉浅，绝知此事要躬行。安全研究离不开可重复的实验环境。下面我将手把手带你搭建一个存在漏洞的Nacos环境，并使用两种最常用的工具进行复现验证。

3.1 搭建存在漏洞的Nacos测试环境

为了安全且方便地实验，我们使用Docker在本地快速搭建一个单机版的Nacos 1.4.2（该版本受漏洞影响）。

步骤1：拉取特定版本镜像并启动

# 拉取Nacos 1.4.2版本镜像 docker pull nacos/nacos-server:1.4.2 # 以单机模式运行，并映射8848端口到本地 docker run -d \ --name nacos-unsafe \ -p 8848:8848 \ -e MODE=standalone \ nacos/nacos-server:1.4.2

这里的关键是-e MODE=standalone，此模式下的1.4.2版本默认未开启认证。

步骤2：验证服务并准备测试数据等待几十秒后，在浏览器访问http://localhost:8848/nacos。你应该能直接看到登录页，但注意，直接点击登录或访问核心API，无需凭证即可成功。为了后续复现，我们先通过API创建一个测试配置，模拟真实环境：

# 使用curl命令，在不提供任何认证信息的情况下，发布一个配置 curl -X POST 'http://localhost:8848/nacos/v1/cs/configs' \ -H 'Content-Type: application/x-www-form-urlencoded' \ -d 'dataId=test-data&group=DEFAULT_GROUP&content=username=admin&password=ThisIsASecret123!'

这个命令会创建一个dataId为test-data，内容包含模拟敏感信息的配置项。如果返回true，说明配置发布成功，同时也证明了API接口处于未授权访问状态。

3.2 使用Burp Suite进行手动复现与探测

Burp Suite是Web安全测试的“瑞士军刀”，我们用它来系统性地探测漏洞。

1. 浏览器代理设置：将浏览器代理指向Burp Suite（默认127.0.0.1:8080）。
2. 访问Nacos控制台：在浏览器中输入http://localhost:8848/nacos。Burp的Proxy模块会捕获到所有HTTP请求。
3. 绕过登录界面：在登录页面，随意输入用户名密码点击登录。捕获到这个POST登录请求（通常发往/nacos/v1/auth/users/login）后，在Burp的Proxy -> Intercept标签页，直接点击“Forward”放行这个请求。你会发现，浏览器竟然跳转到了Nacos的主控制台界面。这是因为服务端在认证未开启时，对登录请求的处理逻辑存在缺陷，允许了这次会话的建立。
4. 验证管理功能：此时，你可以在控制台内任意操作：查看配置列表、服务列表、创建新的命名空间等。所有操作均无需真实凭证。
5. 直接API请求：更直接的验证是使用Burp的Repeater模块。发送一个GET请求到http://localhost:8848/nacos/v1/cs/configs?dataId=test-data&group=DEFAULT_GROUP。你应该能直接收到之前创建的配置内容，响应头中不会有任何要求认证的提示（如401、403）。

实操心得：在实际渗透测试中，我们往往不是从登录页入手。更常见的做法是直接对:8848端口进行路径爆破，尝试直接访问/nacos/v1/cs/configs、/nacos/v1/ns/service/list等已知API路径。用Burp的Intruder模块或gobuster等工具，可以快速批量验证这些端点是否可未授权访问。

3.3 使用Python脚本进行自动化验证与利用

对于批量资产检测或集成到自动化工具链中，编写脚本更方便。下面是一个简单的Python验证脚本，它尝试访问关键API并提取信息。

import requests import sys def check_nacos_unauth(target_url): """ 检查目标Nacos是否存在未授权访问漏洞 :param target_url: Nacos控制台基础URL，如 http://target:8848 """ vuln_endpoints = { 'config_list': '/nacos/v1/cs/configs?pageNo=1&pageSize=10', 'service_list': '/nacos/v1/ns/service/list?pageNo=1&pageSize=10', 'namespace_list': '/nacos/v1/console/namespaces', } headers = {'User-Agent': 'Mozilla/5.0 (Security Test)'} results = {} for name, endpoint in vuln_endpoints.items(): url = target_url.rstrip('/') + endpoint try: resp = requests.get(url, headers=headers, timeout=10, verify=False) if resp.status_code == 200: # 简单判断响应内容是否包含JSON结构或特定关键词 if 'data' in resp.text or 'serviceName' in resp.text or 'namespace' in resp.text: results[name] = {'vulnerable': True, 'data': resp.json() if 'application/json' in resp.headers.get('Content-Type', '') else resp.text[:500]} else: results[name] = {'vulnerable': False, 'reason': 'Unexpected response format'} else: results[name] = {'vulnerable': False, 'reason': f'HTTP {resp.status_code}'} except requests.exceptions.RequestException as e: results[name] = {'vulnerable': False, 'reason': f'Request failed: {e}'} except Exception as e: results[name] = {'vulnerable': False, 'reason': f'Error: {e}'} # 输出结果 print(f"[*] Target: {target_url}") for name, result in results.items(): status = "VULNERABLE" if result.get('vulnerable') else "SAFE" print(f" [-] {name.upper():15} -> {status:12} | Reason: {result.get('reason')}") if result.get('vulnerable') and result.get('data'): print(f" Sample Data: {str(result.get('data'))[:200]}...") # 只打印前200字符 if __name__ == '__main__': if len(sys.argv) != 2: print("Usage: python check_nacos.py <target_url>") sys.exit(1) target = sys.argv[1] check_nacos_unauth(target)

脚本使用与解释：

• 运行：python check_nacos.py http://192.168.1.100:8848
• 脚本会依次请求三个关键接口。判断漏洞存在的依据是：HTTP状态码为200，且响应体中含有业务数据（这里用简单的关键词判断，实际可更严谨）。
• verify=False是为了忽略HTTPS证书验证，仅用于测试环境。生产环境扫描工具应妥善处理证书。
• 这个脚本仅用于验证漏洞存在性和信息泄露，请勿用于未授权的测试。

4. 漏洞根因分析与修复方案

复现成功只是第一步，理解如何修复和防御才是最终目的。修复分为紧急缓解措施和根本解决方案。

4.1 漏洞根因代码层面分析

以Nacos 1.4.x版本为例，问题的核心在于认证过滤器的条件判断。在com.alibaba.nacos.core.auth.AuthFilter类中，对请求进行过滤前，会先检查认证是否启用：

// 伪代码，示意逻辑 if (!authConfig.isAuthEnabled()) { chain.doFilter(request, response); // 认证未启用，直接放行 return; } // ... 后续进行Token校验等逻辑

当nacos.core.auth.enabled为false时，所有请求都会跳过后续的权限校验。然而，管理控制台（/nacos/console/**）和API接口（/nacos/v1/**）本应是需要授权才能访问的资源。在默认配置下，这些路径没有被排除在过滤器之外，导致了未授权访问。

4.2 立即生效的紧急缓解措施

如果线上环境疑似存在漏洞，需要立即采取行动，优先级从高到低：

1. 网络层隔离（最快最有效）：

   • 修改防火墙/安全组策略：立即将Nacos服务器的8848（HTTP）、9848/9849（gRPC，2.x版本）等端口的访问权限收紧。仅允许可信的IP地址或安全组访问，例如只允许运维跳板机、应用服务器所在的网段访问。这是立竿见影的临时解决方案。
   • 使用反向代理增加认证：在Nacos前面部署Nginx或Apache，配置HTTP Basic认证。这是一个快速添加访问控制层的方法。

   # Nginx 配置示例 location /nacos/ { auth_basic "Restricted Access"; auth_basic_user_file /etc/nginx/.htpasswd; # 使用htpasswd创建的用户文件 proxy_pass http://nacos-server:8848; }

2. 应用层快速加固：

   • 启用Nacos认证：这是根本措施。修改Nacos的application.properties或cluster.conf配置文件（位于conf目录下），添加或修改以下行：

     nacos.core.auth.enabled=true nacos.core.auth.system.type=nacos nacos.core.auth.plugin.nacos.token.secret.key=YourSecretKeyHereBase64

     注意：secret.key需要是一个Base64编码的字符串，且长度至少32位。修改后需要重启Nacos集群所有节点。务必先在测试环境验证，因为开启认证后，所有客户端（Spring Cloud应用等）都需要配置对应的用户名密码才能连接。

4.3 长期根本解决方案与最佳实践

紧急措施治标，以下方案治本，并形成安全常态。

1. 升级到安全版本：

   • Nacos官方在漏洞披露后迅速发布了修复版本。对于1.x系列，应升级至1.4.3或更高版本；对于2.x系列，应升级至2.0.4或更高版本。在新版本中，即使认证未开启，控制台访问也会被重定向到登录页，且核心API接口会受到更严格的访问控制。

2. 强制启用并安全配置认证：

   • 在任何生产环境和准生产环境，必须将nacos.core.auth.enabled设置为true。
   • 修改默认密码：首次启动开启认证后，使用默认用户名密码nacos/nacos登录，必须立即修改。
   • 使用强密码策略，并为不同团队或应用创建独立的命名空间和权限账户，遵循最小权限原则。

3. 安全的部署架构：

   • 内外网分离：Nacos控制台管理界面绝不对外网暴露。通过VPN或堡垒机访问。
   • 客户端与服务端通信加密：为Nacos Server配置HTTPS。虽然配置稍复杂，但能防止流量被窃听。
   • 集群部署与高可用：生产环境务必使用集群模式，避免单点故障。同时，集群部署本身也是一种安全增强，因为配置需要在多数节点间同步，增加了篡改难度。

4. 集成企业级身份认证：

   • 对于中大型企业，建议将Nacos与现有的统一身份认证系统（如LDAP/AD、OAuth2、JWT等）集成。Nacos支持自定义插件实现AuthService接口，这样可以复用企业的账号体系和权限管理，实现单点登录和集中审计。

5. 防御体系构建与持续监控

修复一个已知漏洞是点状防御，构建体系化的安全能力才是面状防御。针对配置中心这类核心组件，我们需要建立多层防御和持续监控。

5.1 构建多层次纵深防御体系

将Nacos的安全防护想象成一个洋葱模型，从外到内层层设防：

• 外层：网络与访问控制

  • 安全组/防火墙：严格限制源IP，仅允许应用服务器和运维终端访问。
  • API网关：通过API网关（如Spring Cloud Gateway， Kong）统一暴露和管理Nacos的客户端API（如/nacos/v1/cs/configs），在网关上实施限流、认证和审计。
  • 反向代理：如前所述，可增加一层HTTP基础认证或集成更复杂的认证模块。

• 中层：应用与配置安全

  • 强制认证与强密码：如上文所述，是底线要求。
  • 定期密钥轮换：定期更换nacos.core.auth.plugin.nacos.token.secret.key。轮换时需注意客户端无感更新策略，避免服务中断。
  • 配置内容加密：对于极度敏感的配置项（如密码、私钥），不要以明文形式存储在Nacos中。使用Nacos提供的配置加密功能，或者在使用前由客户端解密。
  • 命名空间隔离：利用Nacos的命名空间功能，将不同项目、不同环境（dev/test/prod）的配置严格隔离。为每个命名空间分配独立的访问权限。

• 内层：审计与运行时安全

  • 开启操作审计：确保Nacos的访问日志和操作日志被完整记录，并接入ELK或Splunk等日志平台，便于追溯谁、在什么时候、做了什么操作。
  • 客户端安全：确保Nacos客户端（如Spring Cloud应用）的username和password不以明文形式写在配置文件中，应使用环境变量或从安全的密钥管理服务（如HashiCorp Vault， AWS Secrets Manager）动态获取。

5.2 漏洞扫描与持续监控方案

安全是一个持续的过程，需要工具和流程来保障。

1. 定期漏洞扫描：

   • 使用Nessus, OpenVAS, AWVS等专业漏洞扫描器，定期对内部网络中的服务（包括Nacos）进行扫描，及时发现类似未授权访问、弱密码等问题。
   • 将CVE-2021-29441等已知漏洞的检测规则固化到扫描策略中。

2. 配置漂移检测：

   • 使用Ansible, Terraform等基础设施即代码工具来管理和部署Nacos的配置。任何对生产环境配置的手工修改都应被视为异常。
   • 可以编写脚本，定期通过Nacos API拉取关键配置的MD5哈希值，与基准值对比，发现未授权的篡改。

3. 异常访问监控与告警：

   • 监控Nacos访问日志，对以下模式建立告警规则：
     • 来自非授权IP地址的访问请求。
     • 短时间内大量失败的登录尝试。
     • 对敏感配置项（如包含password、secret、key等关键词的dataId）的读取或修改操作。
     • 来自未知用户代理（User-Agent）的请求。
   • 可以将Nacos的审计日志输出到Syslog，并接入SIEM（安全信息与事件管理）系统进行关联分析。

5.3 应急响应预案

当监控告警提示Nacos可能存在未授权访问或配置被篡改时，应启动应急响应预案：

1. 确认与隔离：立即通过日志确认攻击来源和影响范围。第一时间通过网络策略隔离受影响实例或整个Nacos集群。
2. 评估影响：检查是否有配置被新增、修改或删除。评估可能泄露的敏感信息（如数据库连接串）和可能被篡改的业务逻辑。
3. 恢复与加固：从备份中恢复被篡改的配置。立即实施前述的紧急缓解措施（如网络隔离、启用认证）。如果漏洞原因是版本过低，规划紧急升级窗口。
4. 溯源与复盘：保留所有日志和证据，进行攻击溯源。召开复盘会议，分析漏洞被利用的根本原因（是未升级？配置错误？还是流程缺失？），并更新安全配置清单和部署手册。

6. 从漏洞复现到安全左移的思考

完成一次漏洞复现，拿到一个“漏洞存在”的结果，仅仅是安全工作的起点。真正的价值在于将这次复现过程中获得的认知，融入到日常的开发、运维和架构设计中去，实现“安全左移”。

我在多次内部培训和项目复盘中发现，很多团队在快速业务迭代的压力下，最容易忽略的就是中间件和基础组件的安全配置。大家习惯于使用默认的、最方便的配置快速搭建环境，却很少去仔细阅读官方文档中关于安全的那一章节。CVE-2021-29441给我们敲响了警钟：在云原生时代，一个配置中心的漏洞，其破坏力可能不亚于一个应用层的SQL注入。

因此，我推动团队建立了“基础组件安全清单”制度。任何新的中间件（Nacos， Apollo， Redis， Kafka等）在上线前，都必须由负责人对照清单完成安全配置核查，清单中就包括“是否启用认证”、“默认密码是否修改”、“网络端口是否最小化开放”、“日志审计是否开启”等关键项。这份清单是动态更新的，每当有新的相关CVE披露，我们就会评估并更新清单内容。

此外，在CI/CD流水线中，我们引入了针对基础设施配置的静态检查。例如，使用Checkov、Terrascan等工具扫描Terraform代码，确保创建的安全组规则不会向0.0.0.0/0开放Nacos的管理端口。在容器镜像构建阶段，会扫描基础镜像和所安装软件包的已知漏洞。

最后，我想分享一个在复杂微服务架构中排查Nacos客户端连接问题的技巧。当你开启服务端认证后，客户端连接失败，除了检查用户名密码，更要注意客户端所在的网络环境与Nacos服务器之间的时钟是否同步。因为Nacos的JWT token校验对时间非常敏感，如果时钟偏差超过一定范围（通常是几分钟），即使密码正确，认证也会失败。我们曾经就踩过这个坑，某台物理机的时间同步服务异常，导致部署其上的所有微服务都无法从Nacos拉取配置，问题现象非常隐蔽。所以，将集群内所有节点的时间同步（NTP）服务列为关键依赖项，是保障包括Nacos在内的众多分布式组件稳定运行的一个基础却极易被忽视的要点。