2023年夏天，限绕我帮一个客户做内网渗透测试。过漏目标系统用的限绕是Nacos 2.2.0，部署在内网一台CentOS上，过漏前面挂了Nginx做反代，限绕加了Basic Auth。过漏客户觉得这样已经够安全了——毕竟外网访问不到，限绕内网还得过一层认证。过漏结果我花了不到十分钟就拿到了Nacos的限绕管理员权限，连Basic Auth都没触发。过漏

问题出在Nacos的限绕一个默认配置上。

绕过是过漏怎么发生的

Nacos在2.2.0版本之前，默认关闭了鉴权。限绕准确地说，过漏nacos.core.auth.enabled这个参数默认值是限绕false。很多人部署完Nacos之后压根没注意这个配置，或者注意到了但觉得"内网嘛，无所谓"。问题是，Nacos的API接口并不会因为你前面套了Nginx Basic Auth就安全——攻击者只要能直接访问到Nacos的8848端口，就能完全绕过Nginx那层认证。

我当时的操作很简单：扫到8848端口开放，直接请求/nacos/v1/auth/users?pageNo=1&pageSize=9，返回了用户列表。然后构造一个添加用户的请求，POST到/nacos/v1/auth/users，带上username=evil&password=evil，直接创建了一个新管理员。全程没有任何认证拦截。

更离谱的是，即便管理员后来在配置里开启了鉴权（nacos.core.auth.enabled=true），已经存在的未授权访问漏洞仍然可以被利用来读取配置信息——因为部分接口的鉴权逻辑存在缺陷。具体来说，Nacos使用JWT做token校验，但SecretKey的默认值硬编码在代码里，是SecretKey012345678901234567890123456789012345678901234567890123456789。这个key在GitHub上公开可见。攻击者可以自己签发一个合法token，完全绕过认证。

真实环境比想象中更脆弱

我后来在几个不同客户的環境里都验证过这个问题。有一家做电商的公司，Nacos集群三节点部署在K8s里，Service没有做网络策略限制，集群内任何Pod都能访问8848端口。他们开了鉴权，但没改默认SecretKey。我用默认key签了一个token，直接调/nacos/v1/ns/operator/metrics拿到了集群状态，再通过配置管理接口读取了数据库连接串和Redis密码。

这件事的严重性在于：Nacos通常管理着整个微服务体系的配置信息。数据库密码、消息队列凭证、第三方API Key，全在里面。拿到Nacos权限，基本等于拿到了整个业务系统的命脉。

修复建议不是"升级就完事了"

官方在2.2.0.1和2.2.1版本里修了默认SecretKey的问题，但升级并不能自动解决所有问题。你需要做几件事：

把nacos.core.auth.enabled设为true，nacos.core.auth.enable.userAgentAuthWhite设为false，然后务必修改nacos.core.auth.plugin.nacos.token.secret.key为一个足够长的随机字符串。Base64编码后至少32位。别用默认值，别用简单字符串。

网络层面，Nacos的8848端口绝对不应该暴露给不可信网络。K8s环境里加NetworkPolicy，传统环境用iptables或安全组限制来源IP。Nginx反代那层Basic Auth对直接端口访问毫无意义。

还有一点容易被忽略：Nacos的/nacos/v1/auth/users接口在未授权情况下可以枚举用户列表。即使开了鉴权，如果SecretKey泄露，攻击者依然可以伪造token。所以SecretKey的保管级别应该等同于数据库密码。

我见过太多团队把Nacos当成"内部工具"来对待，觉得内网就是安全的。现实是，内网横向移动的成本远比大多数人想象的低。一个未授权的Nacos接口，可能就是整个内网沦陷的起点。