1. 项目概述一次对Nacos安全风险的深度梳理最近在梳理内部微服务架构的安全基线Nacos作为核心的注册与配置中心其安全性自然是重中之重。我花了几天时间把截止到2024年9月12日公开披露的、与Nacos相关的安全漏洞和常见风险点系统地整理了一遍。这不仅仅是简单的漏洞列表罗列而是结合了我自己搭建测试环境、复现分析以及思考加固方案的全过程。我发现很多团队在快速引入Nacos实现服务发现和配置管理的同时往往忽略了其默认配置下的安全隐患从弱口令、未授权访问到一些需要特定条件的注入漏洞风险链其实非常清晰。这次整理分为上下两篇上篇主要聚焦在身份认证与访问控制层面的问题包括最典型的弱口令、未授权访问、JWT利用、用户管理漏洞和身份验证绕过以及一个经典的Derby SQL注入案例。下篇则会涉及RCE、反序列化等更高危的漏洞。无论你是安全工程师、运维人员还是开发负责人了解这些风险点并实施恰当的加固措施对于保障整个微服务体系的安全都至关重要。2. Nacos安全风险全景与核心思路拆解在深入每个漏洞细节之前我们有必要先理解Nacos在安全设计上的一些特点以及攻击者通常的切入视角。Nacos作为一个面向内部网络的服务其默认安装往往追求开箱即用的便捷性这在某种程度上牺牲了部分安全性预设。攻击者的核心目标无非是获取控制权、窃取敏感数据配置信息、或作为跳板进一步渗透。围绕Nacos的攻击面主要分布在以下几个层面2.1 认证与授权层面这是最普遍、也最容易被利用的层面。默认的弱口令、未开启认证导致的未授权访问、以及认证逻辑本身存在的绕过缺陷都直接导致攻击者可以“合法”登录管理界面。一旦进入几乎等同于掌控了所有注册的服务实例和可能包含数据库密码、第三方密钥的配置信息。2.2 Web应用层面Nacos本身是一个Java Web应用运行着Spring Boot等框架。因此它不可避免地会继承或引入这些框架及依赖组件的安全漏洞例如早期的Spring Cloud Gateway漏洞CVE-2022-22947虽然不直接是Nacos的漏洞但若网关与Nacos搭配使用且存在漏洞风险会传导。此外Nacos自身的接口也可能存在输入验证不严的问题如SQL注入、JWT伪造逻辑缺陷等。2.3 配置与依赖层面Nacos支持多种数据库作为持久化存储默认使用内嵌的Apache Derby。针对Derby的特定SQL注入漏洞就是一个例子。同时Nacos所依赖的第三方库如果存在已知漏洞例如某些JSON解析库、网络协议库的漏洞也会间接影响Nacos的安全性。2.4 网络与部署层面是否错误地将Nacos控制台暴露在公网是否使用了默认端口而未加防火墙限制是否在以高权限如root运行Nacos进程这些部署上的疏忽会成倍放大上述应用层风险。我这次整理的思路就是沿着“外部访问 - 认证绕过 - 权限提升 - 数据窃取/控制”这条攻击链将公开的漏洞和常见错误配置归类并逐一分析其原理、复现条件及加固方法。我们首先从最简单的“敲门砖”——弱口令开始。3. 核心漏洞解析与复现实操要点3.1 弱口令漏洞最直接的突破口这几乎不算是“漏洞”而是一种危险的安全现状。Nacos在默认安装后控制台存在预置的用户名和密码。3.1.1 漏洞原理与默认凭证在Nacos 1.2.0版本之前默认的控制台账号为nacos密码同样是nacos。即便在后续版本中官方建议在首次启动时通过SQL脚本或修改配置来设置密码但很多匆忙上线的生产环境运维人员可能直接使用了默认配置或者设置了极其简单的密码如admin/admin123,nacos/123456。攻击者通过扫描公网暴露的Nacos控制台地址默认8848端口使用常见弱口令字典进行爆破成功率不容小觑。3.1.2 复现过程与影响复现过程极其简单。假设目标地址为http://192.168.1.100:8848/nacos。访问登录页面。在用户名和密码框中尝试输入nacos/nacos。如果登录成功攻击者将获得完整控制权。登录后攻击者可以查看所有服务获取整个微服务架构的全景图了解系统组成。管理服务实例可以对注册的服务进行上线、下线操作直接导致服务中断。窃取配置信息在“配置管理”中可能存储着数据库连接串、Redis密码、OSS密钥、业务敏感参数等。这是最具破坏性的后果。创建新用户如果权限允许可以创建后门账户维持持久化访问。注意不要认为内网环境就安全。在内网横向移动中攻击者一旦攻破一台主机往往会扫描内网中这类带有默认口令的管理系统Nacos是重点目标之一。3.1.3 加固措施强制修改默认密码安装后第一件事就是修改nacos用户的密码并设置为强密码长度、复杂度。启用并配置认证确保application.properties或application.yml中nacos.core.auth.enabledtrue已开启。使用外部数据库存储用户避免使用内嵌Derby迁移到MySQL或PostgreSQL并定期审计用户表。部署登录失败锁定策略虽然Nacos原生不支持但可以通过前置的Nginx/Apache配置WAF规则或使用第三方安全组件实现短时间内多次失败登录锁定IP的功能。3.2 未授权访问漏洞认证形同虚设比弱口令更严重的情况是认证功能被直接关闭或可以绕过导致无需任何凭证即可访问管理接口。3.2.1 漏洞原理Nacos的认证功能并非强制开启。如果运维人员在配置文件中显式地将nacos.core.auth.enabled设置为false或者在某些特定版本、特定部署方式下如某些Docker镜像的默认配置认证功能处于关闭状态。此时任何访问Nacos API或UI的用户都拥有最高权限。此外历史上存在过一些特定的未授权访问漏洞例如通过构造特定的API路径或参数绕过认证检查逻辑。这类漏洞需要及时更新版本修复。3.2.2 复现与检测检测未授权访问非常简单直接访问Nacos的服务列表APIhttp://:8848/nacos/v1/ns/service/list?pageNo1pageSize10或者访问配置查询APIhttp://:8848/nacos/v1/cs/configs?dataIdgroup如果返回了正常的服务列表或配置内容而没有返回{code:403,message:unknown user!}等错误则证明存在未授权访问。通过浏览器访问控制台首页如果无需登录就直接跳转到了主管理界面则是UI层面的未授权访问。3.2.3 加固措施始终开启认证生产环境必须确保nacos.core.auth.enabledtrue。网络层隔离绝不将Nacos控制台和API端口默认8848暴露到公网。应置于内部网络通过VPN或堡垒机访问。对外只暴露服务发现Client所需的端口如9848、9849用于gRPC但同样建议内网访问。使用安全框架可以考虑在Nacos外层套一层Spring Security或通过网关如Spring Cloud Gateway统一做认证鉴权对/nacos/**路径进行拦截。定期更新版本关注Nacos官方安全公告及时修复已知的未授权绕过漏洞。3.3 JWT密钥硬编码与伪造漏洞JWTJSON Web Token是Nacos用于身份验证的一种机制。当用户登录成功后服务端会返回一个JWT Token客户端在后续请求中携带此Token以维持会话。这里的安全风险集中在JWT的密钥上。3.3.1 漏洞原理在Nacos早期的一些版本中例如围绕1.4.0版本的一段时间用于签名JWT Token的密钥Secret Key是硬编码在代码中的。默认的密钥是公开的字符串例如SecretKey012345678901234567890123456789012345678901234567890123456789。如果攻击者知道了这个密钥他就可以伪造任意用户的JWT Token如用户名设为nacos。自行设定Token的过期时间制作一个“永不过期”的Token。使用这个伪造的Token直接访问Nacos API获得相应权限。3.3.2 漏洞复现实操复现此漏洞需要两个步骤获取默认密钥和伪造Token。信息收集首先需要确认目标Nacos版本是否在受影响范围内。可以通过访问/nacos/查看页面底部版本信息或通过一些无害的API接口反馈判断。伪造Token使用已知的硬编码密钥通过JWT工具如在线网站jwt.io或Python库pyjwt生成Token。Header:{alg:HS256,typ:JWT}Payload:{sub:nacos,exp:9999999999}(这里exp设为一个很大的未来时间戳)Verify Signature: 使用硬编码密钥SecretKey012345678901234567890123456789012345678901234567890123456789进行HS256签名。利用Token将生成的Token字符串在访问Nacos API时以参数accessToken的形式附带例如http://:8848/nacos/v1/ns/service/list?accessToken你的伪造Token。如果返回了数据则利用成功。3.3.3 加固措施升级版本立即升级到已修复此问题的Nacos版本。新版本会要求用户在配置文件中自定义一个高强度的密钥。自定义强密钥在配置文件application.properties中必须修改nacos.core.auth.default.token.secret.key的值为一个你自己生成的、足够长且随机的字符串。切勿使用默认值或简单字符串。定期轮换密钥虽然Nacos本身不支持动态轮换但在安全要求极高的场景可以制定计划定期修改此密钥并重启服务注意会导致所有已登录用户Token失效。3.4 未授权添加用户漏洞这是一个逻辑漏洞存在于特定的API接口中。即使开启了认证攻击者也可能通过一个未受权限控制的API直接添加管理员用户。3.4.1 漏洞原理与影响路径在Nacos的某些版本中用于创建用户的HTTP API接口通常是POST /nacos/v1/auth/users可能存在鉴权缺陷。正常流程下创建用户需要管理员权限。但如果该接口的权限校验逻辑存在漏洞攻击者可以在未登录或低权限登录的情况下直接向该接口发送POST请求成功创建一个新的用户例如用户名hacker密码hacker123并可能赋予其管理员角色。一旦成功攻击者就拥有了一个合法的、受控的高权限账户可以长期、稳定地访问Nacos其威胁比一次性的未授权访问或Token伪造更为持久。3.4.2 复现过程复现需要借助Burp Suite或Postman等工具发送构造的HTTP请求。确定目标Nacos地址http://victim:8848构造POST请求URL:http://victim:8848/nacos/v1/auth/usersHeaders:Content-Type: application/x-www-form-urlencodedBody:usernamehackerpasswordhacker123发送请求。如果返回{code:200,message:create user ok!}或类似成功信息则漏洞存在。随后即可使用新创建的hacker账户登录控制台。3.4.3 加固与检测版本升级关注官方安全更新及时修复此类逻辑漏洞。API审计对Nacos的所有管理API特别是/v1/auth/下的接口进行审计确保其都经过了严格的权限校验。可以通过检查代码或使用API安全测试工具进行扫描。网络监控监控对POST /nacos/v1/auth/users这类敏感接口的调用特别是来自非信任源的请求。3.5 身份验证绕过漏洞合集除了上述具体的漏洞历史上Nacos还存在过一些通过特殊技巧绕过整个认证框架的案例。这些漏洞通常更为精巧利用了URL解析、参数处理或过滤器链中的逻辑错误。3.5.1 常见绕过手法URL路径遍历/规范化问题例如通过添加/../、/./、;、//等特殊字符或利用URL解码差异使请求绕过认证过滤器匹配的路径规则直接访问到后台接口。例如可能/nacos/需要认证但/nacos;/或/nacos/../nacos/被错误地放行了。HTTP方法混淆认证过滤器可能只拦截了GET、POST请求而忽略了PUT、DELETE、PATCH等其他HTTP方法。攻击者尝试用非常规方法访问接口可能绕过检查。请求参数污染在请求中附加多个相同名称的参数如?a1a2后端处理逻辑与前端过滤器逻辑不一致可能导致权限判断失效。特定Header绕过早期某些版本可能通过检查特定的HTTP Header如X-Forwarded-For来判断是否内部请求攻击者可以伪造这些Header。3.5.2 检测与防御思路这类漏洞没有统一的复现步骤依赖于对特定版本具体缺陷的利用。防御需要多层面进行保持版本最新这是防御已知绕过漏洞最有效的方法。使用WAFWeb应用防火墙在Nacos前端部署WAF可以拦截常见的路径遍历、参数污染等攻击payload。强化应用自身过滤器确保认证过滤器的URL模式匹配严谨对所有管理接口生效并且考虑所有HTTP方法。最小权限原则即使存在绕过如果后端接口本身还进行了角色权限校验而非仅仅通过过滤器也能起到第二道防线的作用。因此确保Nacos内部的权限模型配置正确。3.6 CVE-2021-29441: Derby SQL注入漏洞这是一个经典的二次注入漏洞影响范围是使用内嵌Derby数据库且启用了认证功能的Nacos。3.6.1 漏洞原理深度解析这个漏洞的链条比较有趣入口点Nacos的用户认证信息用户名、密码存储在内置的Derby数据库中。触发点在UPDATE用户密码的功能中代码逻辑存在缺陷。当更新密码时它会先根据用户名username查询出该用户的老密码然后将老密码作为WHERE子句的一部分拼接到SQL语句中。注入点关键在于这个用于查询的username参数在之前创建用户INSERT时并未进行充分的过滤。攻击者可以在创建用户时将用户名username设置为一个包含SQL注入payload的字符串例如test。触发当后续尝试修改这个恶意用户的密码时拼接出的SQL语句就会发生语法错误或执行非预期操作。例如查询老密码的语句可能变成SELECT password FROM users WHERE username test导致单引号逃逸。而在后续的UPDATE语句中这个被逃逸的SQL片段可能被部分执行。简单来说漏洞利用了“创建用户时输入未严格过滤”和“更新密码时使用了未经验证的老数据”这两个环节的组合属于“存储型”或“二次”SQL注入。3.6.2 复现环境搭建与利用由于涉及多个步骤复现需要在受影响的版本如Nacos 1.4.0上搭建测试环境。搭建环境使用Docker快速启动一个存在漏洞的Nacos版本docker run --name nacos- vul -p 8848:8848 -e MODEstandalone nacos/nacos-server:1.4.0开启认证进入容器修改conf/application.properties设置nacos.core.auth.enabledtrue重启Nacos。利用过程 a.创建注入用户使用API或UI尝试创建一个用户用户名为注入payload例如victim。注意由于前端可能校验通常需要通过直接发送POST请求到/nacos/v1/auth/users接口Body为usernamevictimpasswordanypass。 b.触发注入调用修改密码的APIPUT /nacos/v1/auth/users尝试修改这个victim用户的密码。此时后端拼接SQL语句时会出错。 c.利用结果经典的利用方式是“时间盲注”。通过构造更复杂的用户名如victim AND (SELECT SLEEP(5) FROM DUAL) AND 11在更新密码时如果数据库执行了SLEEP(5)则请求响应会延迟5秒从而证明注入存在并可以进一步利用读取数据库信息。3.6.3 加固措施升级版本官方已在后续版本中修复此漏洞升级是最直接的方案。使用外部数据库生产环境强烈建议不使用内嵌Derby而是配置MySQL或PostgreSQL。这些成熟数据库的客户端驱动通常对SQL注入有更好的防御支持如预编译语句且Nacos针对它们的代码可能更健壮。输入验证与参数化查询从代码层面对所有用户输入进行严格的校验和过滤在数据库操作中强制使用参数化查询PreparedStatement而非字符串拼接这是根治SQL注入的方法。4. 综合加固方案与配置实操分析了这么多漏洞最终要落实到如何构建一个安全的Nacos环境。下面是一套从部署到配置的实操加固方案。4.1 安全部署实践网络隔离绝不公网暴露Nacos Server的控制台端口默认8848和所有客户端端口如9848, 9849仅在内网开放。使用跳板机/VPN运维人员通过跳板机或VPN访问内网再连接Nacos。客户端访问控制如果微服务部署在多云或混合云环境考虑使用专线或VPN打通网络而非将Nacos Server放在公网让客户端连接。服务运行身份禁止使用root用户直接运行Nacos。创建一个专用的、低权限的系统用户如nacos来运行服务。在Docker中使用-u参数指定非root用户UID例如-u 1000:1000。使用最新稳定版定期关注 Nacos GitHub Releases 和 安全公告 及时升级。升级前务必在测试环境充分验证。4.2 关键安全配置详解修改Nacos的conf/application.properties文件以下是关键安全配置项# 1. 强制开启认证 nacos.core.auth.enabledtrue # 2. 自定义一个高强度、随机的JWT密钥长度建议64位以上 nacos.core.auth.default.token.secret.keyYourOwnVeryLongAndRandomSecretKeyHereAtLeast64Characters1234567890 # 3. 启用服务身份识别防止非法客户端注册 nacos.core.auth.enable.userAgentAuthWhitefalse # 关闭UA白名单采用更严格的校验 nacos.core.auth.server.identity.keyyour-server-identity-key # 服务端标识 nacos.core.auth.server.identity.valueyour-server-identity-value # 服务端标识值 # 客户端配置中需对应设置相同的key和value # 4. 使用外部MySQL数据库强烈推荐生产环境使用 spring.datasource.platformmysql db.num1 db.url.0jdbc:mysql://your-mysql-host:3306/nacos?characterEncodingutf8connectTimeout1000socketTimeout3000autoReconnecttrueuseSSLfalse db.user.0nacos_user db.password.0YourStrongDBPassword! # 5. 修改默认端口可选增加攻击者扫描成本 server.port8849 # 6. 限制管理API的访问通过Nginx等反向代理实现非Nacos原生配置 # 在Nginx中配置只允许特定管理IP访问 /nacos/v1/auth/ 和 /nacos/v1/ns/operator/ 等管理接口4.3 通过反向代理增强安全在生产环境前部署Nginx或Apache可以增加一层防护IP白名单限制/nacos/路径仅能从运维网络IP段访问。速率限制对登录接口进行限流防止爆破。路径重写/隐藏将/nacos重写为其他不易猜测的路径。设置强化的HTTPS配置TLS 1.2禁用弱加密套件。一个简单的Nginx配置片段示例server { listen 443 ssl; server_name nacos.internal.yourcompany.com; ssl_certificate /path/to/cert.pem; ssl_certificate_key /path/to/key.pem; location /nacos/ { # IP白名单 allow 10.0.0.0/8; allow 192.168.1.0/24; deny all; # 代理到后端Nacos proxy_pass http://localhost:8848; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }5. 常见问题排查与安全巡检清单在实际运维和安全巡检中经常会遇到一些典型问题。这里我整理了一份自查清单和排查指南。5.1 安全巡检清单定期如每月执行以下检查检查项检查方法达标标准修复建议认证是否开启访问/nacos/v1/ns/service/list未授权应返回403。必须开启并返回403错误。修改application.properties设置nacos.core.auth.enabledtrue并重启。默认密码是否修改尝试使用nacos/nacos登录控制台。必须无法登录。登录后立即在“权限控制”-“用户管理”中修改nacos用户密码。JWT密钥是否为默认检查配置文件中nacos.core.auth.default.token.secret.key的值。必须为一串自定义的长随机字符串非默认值。生成高强度随机字符串如用openssl rand -base64 48替换并重启。是否使用内嵌Derby检查配置文件中spring.datasource.platform的值。生产环境应为mysql或其它外部数据库。规划迁移至MySQL/PostgreSQL。控制台是否公网可达从公网尝试访问http://your-ip:8848/nacos。必须无法连接或需要VPN。配置防火墙/安全组规则仅允许内网IP访问8848端口。版本是否最新查看控制台底部版本号对比 Nacos Releases 。应使用最新的稳定版。制定升级计划在测试环境验证后升级生产环境。是否存在未知用户登录控制台检查“权限控制”-“用户管理”列表。只存在已知的、必要的用户账户。删除任何未知的、可疑的用户账户。5.2 典型故障排查客户端无法注册/获取配置报“403 unknown user”这是最常见的问题。根本原因是客户端未通过认证。检查点1确认服务端认证已开启nacos.core.auth.enabledtrue。检查点2确认客户端配置中包含了正确的用户名和密码。在Spring Cloud Alibaba Nacos Client中配置应为spring: cloud: nacos: discovery: username: ${nacos.username} password: ${nacos.password} config: username: ${nacos.username} password: ${nacos.password}检查点3检查密码中是否包含特殊字符如,#,在URL传输时可能需要编码。建议在配置中心存储时使用占位符在部署时注入。升级后服务频繁掉线可能因为升级过程中Token生成机制或密钥发生变化。操作重启所有客户端应用使其重新从服务端获取有效的Token。确保服务端密钥配置在升级前后一致如果自定义过。控制台登录缓慢或失败可能原因1数据库尤其是Derby性能瓶颈。解决迁移至MySQL。可能原因2密钥强度太高导致JWT签名/验证计算耗时。解决平衡安全与性能密钥长度适中如64字符并使用性能较好的服务器。5.3 监控与日志审计安全离不开监控。重点关注Nacos日志logs/nacos.log中的频繁的登录失败记录可能为爆破。来自异常IP地址的访问请求。用户管理、配置修改等敏感操作日志。 建议将Nacos日志接入ELKElasticsearch, Logstash, Kibana或类似日志平台设置告警规则例如同一IP一分钟内登录失败超过10次即触发告警。安全是一个持续的过程而非一劳永逸的任务。对Nacos而言从简单的修改默认密码、开启认证到复杂的网络隔离、API审计和漏洞跟踪每一层措施都在增加攻击者的成本。我个人的体会是大多数安全事件都源于对“默认配置”和“便利性”的过度依赖。在微服务架构中像Nacos这样的基础组件一旦被突破整个系统的秘密将一览无余。因此在享受其带来的敏捷与高效的同时务必为其套上坚固的安全铠甲。定期回顾这份清单将其纳入你的运维常规流程能让你的系统在黑夜中更加安稳。
Nacos安全漏洞深度解析：从弱口令到SQL注入的攻防实战
1. 项目概述一次对Nacos安全风险的深度梳理最近在梳理内部微服务架构的安全基线Nacos作为核心的注册与配置中心其安全性自然是重中之重。我花了几天时间把截止到2024年9月12日公开披露的、与Nacos相关的安全漏洞和常见风险点系统地整理了一遍。这不仅仅是简单的漏洞列表罗列而是结合了我自己搭建测试环境、复现分析以及思考加固方案的全过程。我发现很多团队在快速引入Nacos实现服务发现和配置管理的同时往往忽略了其默认配置下的安全隐患从弱口令、未授权访问到一些需要特定条件的注入漏洞风险链其实非常清晰。这次整理分为上下两篇上篇主要聚焦在身份认证与访问控制层面的问题包括最典型的弱口令、未授权访问、JWT利用、用户管理漏洞和身份验证绕过以及一个经典的Derby SQL注入案例。下篇则会涉及RCE、反序列化等更高危的漏洞。无论你是安全工程师、运维人员还是开发负责人了解这些风险点并实施恰当的加固措施对于保障整个微服务体系的安全都至关重要。2. Nacos安全风险全景与核心思路拆解在深入每个漏洞细节之前我们有必要先理解Nacos在安全设计上的一些特点以及攻击者通常的切入视角。Nacos作为一个面向内部网络的服务其默认安装往往追求开箱即用的便捷性这在某种程度上牺牲了部分安全性预设。攻击者的核心目标无非是获取控制权、窃取敏感数据配置信息、或作为跳板进一步渗透。围绕Nacos的攻击面主要分布在以下几个层面2.1 认证与授权层面这是最普遍、也最容易被利用的层面。默认的弱口令、未开启认证导致的未授权访问、以及认证逻辑本身存在的绕过缺陷都直接导致攻击者可以“合法”登录管理界面。一旦进入几乎等同于掌控了所有注册的服务实例和可能包含数据库密码、第三方密钥的配置信息。2.2 Web应用层面Nacos本身是一个Java Web应用运行着Spring Boot等框架。因此它不可避免地会继承或引入这些框架及依赖组件的安全漏洞例如早期的Spring Cloud Gateway漏洞CVE-2022-22947虽然不直接是Nacos的漏洞但若网关与Nacos搭配使用且存在漏洞风险会传导。此外Nacos自身的接口也可能存在输入验证不严的问题如SQL注入、JWT伪造逻辑缺陷等。2.3 配置与依赖层面Nacos支持多种数据库作为持久化存储默认使用内嵌的Apache Derby。针对Derby的特定SQL注入漏洞就是一个例子。同时Nacos所依赖的第三方库如果存在已知漏洞例如某些JSON解析库、网络协议库的漏洞也会间接影响Nacos的安全性。2.4 网络与部署层面是否错误地将Nacos控制台暴露在公网是否使用了默认端口而未加防火墙限制是否在以高权限如root运行Nacos进程这些部署上的疏忽会成倍放大上述应用层风险。我这次整理的思路就是沿着“外部访问 - 认证绕过 - 权限提升 - 数据窃取/控制”这条攻击链将公开的漏洞和常见错误配置归类并逐一分析其原理、复现条件及加固方法。我们首先从最简单的“敲门砖”——弱口令开始。3. 核心漏洞解析与复现实操要点3.1 弱口令漏洞最直接的突破口这几乎不算是“漏洞”而是一种危险的安全现状。Nacos在默认安装后控制台存在预置的用户名和密码。3.1.1 漏洞原理与默认凭证在Nacos 1.2.0版本之前默认的控制台账号为nacos密码同样是nacos。即便在后续版本中官方建议在首次启动时通过SQL脚本或修改配置来设置密码但很多匆忙上线的生产环境运维人员可能直接使用了默认配置或者设置了极其简单的密码如admin/admin123,nacos/123456。攻击者通过扫描公网暴露的Nacos控制台地址默认8848端口使用常见弱口令字典进行爆破成功率不容小觑。3.1.2 复现过程与影响复现过程极其简单。假设目标地址为http://192.168.1.100:8848/nacos。访问登录页面。在用户名和密码框中尝试输入nacos/nacos。如果登录成功攻击者将获得完整控制权。登录后攻击者可以查看所有服务获取整个微服务架构的全景图了解系统组成。管理服务实例可以对注册的服务进行上线、下线操作直接导致服务中断。窃取配置信息在“配置管理”中可能存储着数据库连接串、Redis密码、OSS密钥、业务敏感参数等。这是最具破坏性的后果。创建新用户如果权限允许可以创建后门账户维持持久化访问。注意不要认为内网环境就安全。在内网横向移动中攻击者一旦攻破一台主机往往会扫描内网中这类带有默认口令的管理系统Nacos是重点目标之一。3.1.3 加固措施强制修改默认密码安装后第一件事就是修改nacos用户的密码并设置为强密码长度、复杂度。启用并配置认证确保application.properties或application.yml中nacos.core.auth.enabledtrue已开启。使用外部数据库存储用户避免使用内嵌Derby迁移到MySQL或PostgreSQL并定期审计用户表。部署登录失败锁定策略虽然Nacos原生不支持但可以通过前置的Nginx/Apache配置WAF规则或使用第三方安全组件实现短时间内多次失败登录锁定IP的功能。3.2 未授权访问漏洞认证形同虚设比弱口令更严重的情况是认证功能被直接关闭或可以绕过导致无需任何凭证即可访问管理接口。3.2.1 漏洞原理Nacos的认证功能并非强制开启。如果运维人员在配置文件中显式地将nacos.core.auth.enabled设置为false或者在某些特定版本、特定部署方式下如某些Docker镜像的默认配置认证功能处于关闭状态。此时任何访问Nacos API或UI的用户都拥有最高权限。此外历史上存在过一些特定的未授权访问漏洞例如通过构造特定的API路径或参数绕过认证检查逻辑。这类漏洞需要及时更新版本修复。3.2.2 复现与检测检测未授权访问非常简单直接访问Nacos的服务列表APIhttp://:8848/nacos/v1/ns/service/list?pageNo1pageSize10或者访问配置查询APIhttp://:8848/nacos/v1/cs/configs?dataIdgroup如果返回了正常的服务列表或配置内容而没有返回{code:403,message:unknown user!}等错误则证明存在未授权访问。通过浏览器访问控制台首页如果无需登录就直接跳转到了主管理界面则是UI层面的未授权访问。3.2.3 加固措施始终开启认证生产环境必须确保nacos.core.auth.enabledtrue。网络层隔离绝不将Nacos控制台和API端口默认8848暴露到公网。应置于内部网络通过VPN或堡垒机访问。对外只暴露服务发现Client所需的端口如9848、9849用于gRPC但同样建议内网访问。使用安全框架可以考虑在Nacos外层套一层Spring Security或通过网关如Spring Cloud Gateway统一做认证鉴权对/nacos/**路径进行拦截。定期更新版本关注Nacos官方安全公告及时修复已知的未授权绕过漏洞。3.3 JWT密钥硬编码与伪造漏洞JWTJSON Web Token是Nacos用于身份验证的一种机制。当用户登录成功后服务端会返回一个JWT Token客户端在后续请求中携带此Token以维持会话。这里的安全风险集中在JWT的密钥上。3.3.1 漏洞原理在Nacos早期的一些版本中例如围绕1.4.0版本的一段时间用于签名JWT Token的密钥Secret Key是硬编码在代码中的。默认的密钥是公开的字符串例如SecretKey012345678901234567890123456789012345678901234567890123456789。如果攻击者知道了这个密钥他就可以伪造任意用户的JWT Token如用户名设为nacos。自行设定Token的过期时间制作一个“永不过期”的Token。使用这个伪造的Token直接访问Nacos API获得相应权限。3.3.2 漏洞复现实操复现此漏洞需要两个步骤获取默认密钥和伪造Token。信息收集首先需要确认目标Nacos版本是否在受影响范围内。可以通过访问/nacos/查看页面底部版本信息或通过一些无害的API接口反馈判断。伪造Token使用已知的硬编码密钥通过JWT工具如在线网站jwt.io或Python库pyjwt生成Token。Header:{alg:HS256,typ:JWT}Payload:{sub:nacos,exp:9999999999}(这里exp设为一个很大的未来时间戳)Verify Signature: 使用硬编码密钥SecretKey012345678901234567890123456789012345678901234567890123456789进行HS256签名。利用Token将生成的Token字符串在访问Nacos API时以参数accessToken的形式附带例如http://:8848/nacos/v1/ns/service/list?accessToken你的伪造Token。如果返回了数据则利用成功。3.3.3 加固措施升级版本立即升级到已修复此问题的Nacos版本。新版本会要求用户在配置文件中自定义一个高强度的密钥。自定义强密钥在配置文件application.properties中必须修改nacos.core.auth.default.token.secret.key的值为一个你自己生成的、足够长且随机的字符串。切勿使用默认值或简单字符串。定期轮换密钥虽然Nacos本身不支持动态轮换但在安全要求极高的场景可以制定计划定期修改此密钥并重启服务注意会导致所有已登录用户Token失效。3.4 未授权添加用户漏洞这是一个逻辑漏洞存在于特定的API接口中。即使开启了认证攻击者也可能通过一个未受权限控制的API直接添加管理员用户。3.4.1 漏洞原理与影响路径在Nacos的某些版本中用于创建用户的HTTP API接口通常是POST /nacos/v1/auth/users可能存在鉴权缺陷。正常流程下创建用户需要管理员权限。但如果该接口的权限校验逻辑存在漏洞攻击者可以在未登录或低权限登录的情况下直接向该接口发送POST请求成功创建一个新的用户例如用户名hacker密码hacker123并可能赋予其管理员角色。一旦成功攻击者就拥有了一个合法的、受控的高权限账户可以长期、稳定地访问Nacos其威胁比一次性的未授权访问或Token伪造更为持久。3.4.2 复现过程复现需要借助Burp Suite或Postman等工具发送构造的HTTP请求。确定目标Nacos地址http://victim:8848构造POST请求URL:http://victim:8848/nacos/v1/auth/usersHeaders:Content-Type: application/x-www-form-urlencodedBody:usernamehackerpasswordhacker123发送请求。如果返回{code:200,message:create user ok!}或类似成功信息则漏洞存在。随后即可使用新创建的hacker账户登录控制台。3.4.3 加固与检测版本升级关注官方安全更新及时修复此类逻辑漏洞。API审计对Nacos的所有管理API特别是/v1/auth/下的接口进行审计确保其都经过了严格的权限校验。可以通过检查代码或使用API安全测试工具进行扫描。网络监控监控对POST /nacos/v1/auth/users这类敏感接口的调用特别是来自非信任源的请求。3.5 身份验证绕过漏洞合集除了上述具体的漏洞历史上Nacos还存在过一些通过特殊技巧绕过整个认证框架的案例。这些漏洞通常更为精巧利用了URL解析、参数处理或过滤器链中的逻辑错误。3.5.1 常见绕过手法URL路径遍历/规范化问题例如通过添加/../、/./、;、//等特殊字符或利用URL解码差异使请求绕过认证过滤器匹配的路径规则直接访问到后台接口。例如可能/nacos/需要认证但/nacos;/或/nacos/../nacos/被错误地放行了。HTTP方法混淆认证过滤器可能只拦截了GET、POST请求而忽略了PUT、DELETE、PATCH等其他HTTP方法。攻击者尝试用非常规方法访问接口可能绕过检查。请求参数污染在请求中附加多个相同名称的参数如?a1a2后端处理逻辑与前端过滤器逻辑不一致可能导致权限判断失效。特定Header绕过早期某些版本可能通过检查特定的HTTP Header如X-Forwarded-For来判断是否内部请求攻击者可以伪造这些Header。3.5.2 检测与防御思路这类漏洞没有统一的复现步骤依赖于对特定版本具体缺陷的利用。防御需要多层面进行保持版本最新这是防御已知绕过漏洞最有效的方法。使用WAFWeb应用防火墙在Nacos前端部署WAF可以拦截常见的路径遍历、参数污染等攻击payload。强化应用自身过滤器确保认证过滤器的URL模式匹配严谨对所有管理接口生效并且考虑所有HTTP方法。最小权限原则即使存在绕过如果后端接口本身还进行了角色权限校验而非仅仅通过过滤器也能起到第二道防线的作用。因此确保Nacos内部的权限模型配置正确。3.6 CVE-2021-29441: Derby SQL注入漏洞这是一个经典的二次注入漏洞影响范围是使用内嵌Derby数据库且启用了认证功能的Nacos。3.6.1 漏洞原理深度解析这个漏洞的链条比较有趣入口点Nacos的用户认证信息用户名、密码存储在内置的Derby数据库中。触发点在UPDATE用户密码的功能中代码逻辑存在缺陷。当更新密码时它会先根据用户名username查询出该用户的老密码然后将老密码作为WHERE子句的一部分拼接到SQL语句中。注入点关键在于这个用于查询的username参数在之前创建用户INSERT时并未进行充分的过滤。攻击者可以在创建用户时将用户名username设置为一个包含SQL注入payload的字符串例如test。触发当后续尝试修改这个恶意用户的密码时拼接出的SQL语句就会发生语法错误或执行非预期操作。例如查询老密码的语句可能变成SELECT password FROM users WHERE username test导致单引号逃逸。而在后续的UPDATE语句中这个被逃逸的SQL片段可能被部分执行。简单来说漏洞利用了“创建用户时输入未严格过滤”和“更新密码时使用了未经验证的老数据”这两个环节的组合属于“存储型”或“二次”SQL注入。3.6.2 复现环境搭建与利用由于涉及多个步骤复现需要在受影响的版本如Nacos 1.4.0上搭建测试环境。搭建环境使用Docker快速启动一个存在漏洞的Nacos版本docker run --name nacos- vul -p 8848:8848 -e MODEstandalone nacos/nacos-server:1.4.0开启认证进入容器修改conf/application.properties设置nacos.core.auth.enabledtrue重启Nacos。利用过程 a.创建注入用户使用API或UI尝试创建一个用户用户名为注入payload例如victim。注意由于前端可能校验通常需要通过直接发送POST请求到/nacos/v1/auth/users接口Body为usernamevictimpasswordanypass。 b.触发注入调用修改密码的APIPUT /nacos/v1/auth/users尝试修改这个victim用户的密码。此时后端拼接SQL语句时会出错。 c.利用结果经典的利用方式是“时间盲注”。通过构造更复杂的用户名如victim AND (SELECT SLEEP(5) FROM DUAL) AND 11在更新密码时如果数据库执行了SLEEP(5)则请求响应会延迟5秒从而证明注入存在并可以进一步利用读取数据库信息。3.6.3 加固措施升级版本官方已在后续版本中修复此漏洞升级是最直接的方案。使用外部数据库生产环境强烈建议不使用内嵌Derby而是配置MySQL或PostgreSQL。这些成熟数据库的客户端驱动通常对SQL注入有更好的防御支持如预编译语句且Nacos针对它们的代码可能更健壮。输入验证与参数化查询从代码层面对所有用户输入进行严格的校验和过滤在数据库操作中强制使用参数化查询PreparedStatement而非字符串拼接这是根治SQL注入的方法。4. 综合加固方案与配置实操分析了这么多漏洞最终要落实到如何构建一个安全的Nacos环境。下面是一套从部署到配置的实操加固方案。4.1 安全部署实践网络隔离绝不公网暴露Nacos Server的控制台端口默认8848和所有客户端端口如9848, 9849仅在内网开放。使用跳板机/VPN运维人员通过跳板机或VPN访问内网再连接Nacos。客户端访问控制如果微服务部署在多云或混合云环境考虑使用专线或VPN打通网络而非将Nacos Server放在公网让客户端连接。服务运行身份禁止使用root用户直接运行Nacos。创建一个专用的、低权限的系统用户如nacos来运行服务。在Docker中使用-u参数指定非root用户UID例如-u 1000:1000。使用最新稳定版定期关注 Nacos GitHub Releases 和 安全公告 及时升级。升级前务必在测试环境充分验证。4.2 关键安全配置详解修改Nacos的conf/application.properties文件以下是关键安全配置项# 1. 强制开启认证 nacos.core.auth.enabledtrue # 2. 自定义一个高强度、随机的JWT密钥长度建议64位以上 nacos.core.auth.default.token.secret.keyYourOwnVeryLongAndRandomSecretKeyHereAtLeast64Characters1234567890 # 3. 启用服务身份识别防止非法客户端注册 nacos.core.auth.enable.userAgentAuthWhitefalse # 关闭UA白名单采用更严格的校验 nacos.core.auth.server.identity.keyyour-server-identity-key # 服务端标识 nacos.core.auth.server.identity.valueyour-server-identity-value # 服务端标识值 # 客户端配置中需对应设置相同的key和value # 4. 使用外部MySQL数据库强烈推荐生产环境使用 spring.datasource.platformmysql db.num1 db.url.0jdbc:mysql://your-mysql-host:3306/nacos?characterEncodingutf8connectTimeout1000socketTimeout3000autoReconnecttrueuseSSLfalse db.user.0nacos_user db.password.0YourStrongDBPassword! # 5. 修改默认端口可选增加攻击者扫描成本 server.port8849 # 6. 限制管理API的访问通过Nginx等反向代理实现非Nacos原生配置 # 在Nginx中配置只允许特定管理IP访问 /nacos/v1/auth/ 和 /nacos/v1/ns/operator/ 等管理接口4.3 通过反向代理增强安全在生产环境前部署Nginx或Apache可以增加一层防护IP白名单限制/nacos/路径仅能从运维网络IP段访问。速率限制对登录接口进行限流防止爆破。路径重写/隐藏将/nacos重写为其他不易猜测的路径。设置强化的HTTPS配置TLS 1.2禁用弱加密套件。一个简单的Nginx配置片段示例server { listen 443 ssl; server_name nacos.internal.yourcompany.com; ssl_certificate /path/to/cert.pem; ssl_certificate_key /path/to/key.pem; location /nacos/ { # IP白名单 allow 10.0.0.0/8; allow 192.168.1.0/24; deny all; # 代理到后端Nacos proxy_pass http://localhost:8848; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }5. 常见问题排查与安全巡检清单在实际运维和安全巡检中经常会遇到一些典型问题。这里我整理了一份自查清单和排查指南。5.1 安全巡检清单定期如每月执行以下检查检查项检查方法达标标准修复建议认证是否开启访问/nacos/v1/ns/service/list未授权应返回403。必须开启并返回403错误。修改application.properties设置nacos.core.auth.enabledtrue并重启。默认密码是否修改尝试使用nacos/nacos登录控制台。必须无法登录。登录后立即在“权限控制”-“用户管理”中修改nacos用户密码。JWT密钥是否为默认检查配置文件中nacos.core.auth.default.token.secret.key的值。必须为一串自定义的长随机字符串非默认值。生成高强度随机字符串如用openssl rand -base64 48替换并重启。是否使用内嵌Derby检查配置文件中spring.datasource.platform的值。生产环境应为mysql或其它外部数据库。规划迁移至MySQL/PostgreSQL。控制台是否公网可达从公网尝试访问http://your-ip:8848/nacos。必须无法连接或需要VPN。配置防火墙/安全组规则仅允许内网IP访问8848端口。版本是否最新查看控制台底部版本号对比 Nacos Releases 。应使用最新的稳定版。制定升级计划在测试环境验证后升级生产环境。是否存在未知用户登录控制台检查“权限控制”-“用户管理”列表。只存在已知的、必要的用户账户。删除任何未知的、可疑的用户账户。5.2 典型故障排查客户端无法注册/获取配置报“403 unknown user”这是最常见的问题。根本原因是客户端未通过认证。检查点1确认服务端认证已开启nacos.core.auth.enabledtrue。检查点2确认客户端配置中包含了正确的用户名和密码。在Spring Cloud Alibaba Nacos Client中配置应为spring: cloud: nacos: discovery: username: ${nacos.username} password: ${nacos.password} config: username: ${nacos.username} password: ${nacos.password}检查点3检查密码中是否包含特殊字符如,#,在URL传输时可能需要编码。建议在配置中心存储时使用占位符在部署时注入。升级后服务频繁掉线可能因为升级过程中Token生成机制或密钥发生变化。操作重启所有客户端应用使其重新从服务端获取有效的Token。确保服务端密钥配置在升级前后一致如果自定义过。控制台登录缓慢或失败可能原因1数据库尤其是Derby性能瓶颈。解决迁移至MySQL。可能原因2密钥强度太高导致JWT签名/验证计算耗时。解决平衡安全与性能密钥长度适中如64字符并使用性能较好的服务器。5.3 监控与日志审计安全离不开监控。重点关注Nacos日志logs/nacos.log中的频繁的登录失败记录可能为爆破。来自异常IP地址的访问请求。用户管理、配置修改等敏感操作日志。 建议将Nacos日志接入ELKElasticsearch, Logstash, Kibana或类似日志平台设置告警规则例如同一IP一分钟内登录失败超过10次即触发告警。安全是一个持续的过程而非一劳永逸的任务。对Nacos而言从简单的修改默认密码、开启认证到复杂的网络隔离、API审计和漏洞跟踪每一层措施都在增加攻击者的成本。我个人的体会是大多数安全事件都源于对“默认配置”和“便利性”的过度依赖。在微服务架构中像Nacos这样的基础组件一旦被突破整个系统的秘密将一览无余。因此在享受其带来的敏捷与高效的同时务必为其套上坚固的安全铠甲。定期回顾这份清单将其纳入你的运维常规流程能让你的系统在黑夜中更加安稳。
