nacos漏洞(CNVD-2023674205)复现&踩坑记录

nacos漏洞(CNVD-2023674205)复现&踩坑记录

漏洞披露

3月2日，CNVD披露了编号为CNVD-2023674205的nacos认证绕过漏洞

在nacos官方github项目(https://github.com/alibaba/nacos)发布2.2.0.1版本对应修复版本，移除了默认鉴权插件中依赖的`nacos.core.auth.plugin.nacos.token.secret.key`默认值

漏洞复现&分析

下载2.2.0版本nacos搭建环境，下载链接：https://github.com/alibaba/nacos/releases/download/2.2.0/nacos-server-2.2.0.tar.gz

启动也很简单，先安装好java环境（如何安装java自行搜索 (～￣▽￣)～），进入bin目录下，执行./startsh -m standalone即可

# 解压缩
unzip nacos-server-1.0.0.zip
# 进入bin目录
cd nacos/bin
# 运行nacos 注意添加 -m standalone 
sh startup.sh -m standalone
# 关闭nacos
sh shutdown.sh

根据官方的修复公告，查看配置文件 conf/application.properties，发现nacos.core.auth.plugin.nacos.token.secret.key是有默认值的

而nacos使用jwt构造认证token，使用HS256算法，把配置文件中nacos.core.auth.plugin.nacos.token.secret.key的默认值当作私钥生成Signature，将subject（用户名）和exp戳写到jwt token里

查看源码：nacos-2.2.0\plugin-default-impl\src\main\java\com\alibaba\nacos\plugin\auth\impl\JwtTokenManager.java

其中secretKey即配置文件中nacos.core.auth.plugin.nacos.token.secret.key的值，从JwtTokenManager类的processProperties()函数中可以看到

在jwt token校验的时候，校验了token签名有效性和是否过期（nacos-2.2.0\plugin-default-impl\src\main\java\com\alibaba\nacos\plugin\auth\impl\NacosAuthManager.java）

现在知道了jwt的生成和校验逻辑，以及jwt的默认私钥，就可以伪造jwt token绕过认证nacos认证逻辑，构造一个超长有效期的token，就可以使用poc扫描啦

下面进行验证，以获取配置信息接口为例，首先是没有jwt token访问接口，返回禁止访问

带上Authorization再访问，jwt token使用刚才构造的，成功返回

ps：在老版本中（1.1.4版本及以下），如果nacos没有配置信息，则body中没有数据，仅返回200，所以poc不能以响应包的body为标志进行扫描，若以status_code为标志，则误报会很多

可以删除search参数值，以响应包的body为标志( •̀ ω •́ )✧

ps：0.x.x的远古版本没有登录逻辑。。访问就直接进入系统了

漏洞修复

1.2.0版本及以上的nacos，修改配置文件中的nacos.core.auth.plugin.nacos.token.secret.key即可

1.1.4版本及以下的nacos，由于私钥写死到了代码里，用户无法自行配置，只能升级nacos到最新版

踩过的坑

一开始用登录接口来检测jwt默认私钥漏洞，在1.2.0及以上版本中，使用构造的jwt token访问，发现即使不输入账密，也显示登录成功，接口地址为/nacos/v1/auth/users/login（默认配置启动），响应包中校验200状态码和accessToken字段即可

但在老版本（1.1.4及以下版本）中，接口地址为/nacos/v1/auth/login（默认配置启动），跟新版本的不一样，并且使用了伪造的jwt token也不成功，造成了漏报(っ °Д °;)っ

勾起了好奇心，下载nacos源码一探究竟：

首先是老版本（1.1.4及以前）的源码，登录逻辑为直接比对账密，比对成功即登录成功

而在新版本（1.2.0版本-最新）中，增加了一个header中token的认证逻辑：如果配置文件中的nacos.core.auth.system.type为nacos或者ldap，且请求包含Authorization的header并校验通过，则优先使用请求中的token，可以不用校验账密

配置文件（nacos.core.auth.system.type默认为nacos）：

登录部分的源码（nacos-2.2.0\plugin-default-impl\src\main\java\com\alibaba\nacos\plugin\auth\impl\controller\UserController.java）：

校验通过后，响应包会直接使用请求包中的jwt token

跟进authManager.login(request)函数，到达nacos-2.2.0\plugin-default-impl\src\main\java\com\alibaba\nacos\plugin\auth\impl\NacosAuthManager.java里面

在resolveToken和validate0函数里校验

resolveToken函数用于提取Authorization的值，若以Bearer 为开头，则取第7个字符以后的字符串返回

validate0用于校验jwt token，使用配置的nacos.core.auth.default.token.secret.key

响应包中返回登录成功，响应包中包含请求header中的token，而老版本仅校验账密导致返回登陆失败

所以新版本中使用登录接口验证默认私钥漏洞不适用于老版本，构造一个全版本通杀的poc还是不容易的o(TヘTo)，还是加上获取配置信息接口一块扫吧。。

题外话

1、User-Agent导致的未授权漏洞

nacos历史上曾经爆出过使用特殊构造的User-Agent造成未授权接口访问的漏洞，在翻官方文档（https://nacos.io/zh-cn/docs/auth.html）中发现这么一段话：

由此可见，使用特殊构造的User-Agent是官方用于服务端之间的可信通信，未考虑到暴露公网的情况，在nacos 1.2-1.4.0版本期间存在这个安全问题，在1.4.1及以上版本中，nacos默认配置关闭了这个特性，用户可以手动开启，开启后需要配置自定义的key value对

2、某poc扫描器的小特性

在写poc时，我的expression是这样写的，校验响应包头中是否有Content-Type字段，并判断是否为application/json

看着莫得问题，结果poc扫描器显示poc加载失败

看了看官方文档，也没发现啥问题，文档里也这么用的

调试了半天，发现前面一定要有response.status的判断才能加载成功。。

但是响应包的状态码本来就不确定，可能为200 400 500，所以就没加状态码的判断，结果就卡在这里了。。（不晓得为啥一定要先判断response.status才能检查headers）

被逼无奈，只能写了个response.status != 1来意思一下了(* ￣︿￣)