导航：首页 > 网络安全 >

Nexus Repository Manager 2.x命令注入漏洞CVE-2019-5475示例分析

发表于：2024-12-12 作者：千家信息网编辑

千家信息网最后更新 2024年12月12日，Nexus Repository Manager 2.x命令注入漏洞CVE-2019-5475示例分析，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解

千家信息网最后更新 2024年12月12日Nexus Repository Manager 2.x命令注入漏洞CVE-2019-5475示例分析

Nexus Repository Manager 2.x命令注入漏洞CVE-2019-5475示例分析，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。

前言

2019年9月初我们应急了Nexus Repository Manager 2.x 命令注入漏洞(CVE-2019-5475)，其大致的原因和复现步骤在 hackerone 上公布了，在应急完这个漏洞之后，我们分析该漏洞的修复补丁，发现修复不完全，仍然可以绕过，本篇文章记录该漏洞的两次绕过。虽然早发布了两次的修复版本，由于官方第二次更新公告太慢https://support.sonatype.com/hc/en-us/articles/360033490774，所以现在才发。

几次更新时间线：

CVE-2019-5475（2019-08-09）
第一次绕过，CVE-2019-15588（2019-10-28）
第二次绕过，未分配CVE，更新了公告影响版本（2020-3-25）

注：原始漏洞分析、第一次绕过分析、第二次绕过分析部分主要由Badcode师傅编写，第二次绕过分析+、最新版本分析主要由Longofo添加。

原始漏洞分析

利用条件

需管理员权限(默认认证：admin/admin123)

漏洞分析

以下分析的代码基于 2.14.9-01 版本。

漏洞点是出现在 Yum Repository 插件中，当配置 Yum 的createrepo或者mergerepo时

代码层面会跳到YumCapability的activationCondition方法中。

在上面Path of "createrepo"中设置的值会通过getConfig().getCreaterepoPath()获取到，获取到该值之后，调用this.validate()方法

传进来的path是用户可控的，之后将path拼接--version之后传递给commandLineExecutor.exec()方法，看起来像是执行命令的方法，而事实也是如此。跟进CommandLineExecutor类的exec方法

在执行命令前先对命令解析，CommandLine.parse()，会以空格作为分隔，获取可执行文件及参数。

最终是调用了Runtime.getRuntime().exec()执行了命令。

例如，用户传入的 command 是cmd.exe /c whoami，最后到getRuntime().exec()方法就是Runtime.getRuntime().exec({"cmd.exe","/c","whoami"})。

所以漏洞的原理也很简单，就是在createrepo或者mergerepo路径设置的时候，该路径可以由用户指定，中途拼接了--version字符串，最终到了getRuntime.exec()执行了命令。

漏洞复现

在Path of "createrepo"里面传入 payload。

在Status栏可以看到执行的结果

第一次绕过分析

第一次补丁分析

官方补丁改了几个地方，关键点在这里

常规做法，在执行命令前对命令进行过滤。新增加了一个getCleanCommand()方法，对命令进行过滤。

allowedExecutables是一个 HashSet，里面只有两个值，createrepo和mergerepo。先判断用户传入的command是否在allowedExecutables里面，如果在，直接拼接params即--version直接返回。接着对用户传入的command进行路径判断，如果是以nexus的工作目录(applicationDirectories.getWorkDirectory().getAbsolutePath())开头的，直接返回 null。继续判断，如果文件名不在allowedExecutables则返回 null，也就是这条命令需要以/createrepo或者/mergerepo结尾。都通过判断之后，文件的绝对路径拼接--version返回。

第一次补丁绕过

说实话，看到这个补丁的第一眼，我就觉得大概率可以绕。

传入的命令满足两个条件即可，不以nexus的工作目录开头，并且以/createrepo或者/mergerepo结尾即可。

看到补丁中的getCleanCommand()方法，new File(command)是关键，new File()是通过将给定的路径名字符串转换为抽象路径名来创建新的File实例。值得注意的是，这里面路径字符串是可以使用空格的，也就是

String f = "/etc/passwd /shadow"; File file = new File(f);

这种是合法的，并且调用file.getName()取到的值是shadow。结合这个特性，就可以绕过补丁里面的判断。

String cmd = "/bin/bash -c whoami /createrepo"; File file = new File(cmd); System.out.println(file.getName()); System.out.println(file.getAbsolutePath());

运行结果

可以看到，file.getName()的值正是createrepo，满足判断。

第一次绕过测试

测试环境

2.14.14-01 版本
Linux

测试步骤

在Path of "createrepo"里面传入 payload。

在Status栏查看执行的结果

可以看到，成功绕过了补丁。

在 Windows 环境下面就麻烦点了，没有办法使用cmd.exe /c whoami这种形式执行命令了，因为cmd.exe /c whoami经过new File()之后变成了cmd.exe \c whoami，后面是执行不了的。可以直接执行exe，注意后面是还会拼接--version的，所以很多命令是执行不了的，但是还是有办法利用能执行任意exe这点来做后续的攻击的。

第二次绕过分析

第二次补丁分析

在我提交上述绕过方式后，官方修复了这种绕过方式，看下官方的补丁

在getCleanCommand()方法中增加了一个file.exists()判断文件是否存在。之前的/bin/bash -c whoami /createrepo这种形式的肯定就不行了，因为这个文件并不存在。所以现在又多了一个判断，难度又加大了。难道就没有办法绕过了？不是的，还是可以绕过的。

第二次补丁绕过

现在传入的命令要满足三个条件了

不以nexus的工作目录开头
以/createrepo或者/mergerepo结尾
并且这createrepo或者mergerepo这个文件存在

看到file.exists()我就想起了 php 中的file_exists()，以前搞 php 的时候也遇到过这种判断。有个系统特性，在 Windows 环境下，目录跳转是允许跳转不存在的目录的，而在Linux下面是不能跳转不存在目录的。

测试一下

Linux

可以看到，file.exists()返回了 false

Windows

file.exists()返回了 true

上面我们说了new File(pathname)，pathname 是允许带空格的。在利用上面WIndows环境下的特性，把cmd设置成C:\\Windows\\System32\\calc.exe \\..\\..\\win.ini

经过parse()方法，最终到getRuntime.exec({"C:\\Windows\\System32\\calc.exe","\\..\\..\\win.ini"})，这样就能执行calc了。

在上面这个测试win.ini是确实存在的文件，回到补丁上面，需要判断createrepo或者mergerepo存在。首先从功能上来说，createrepo 命令用于创建 yum 源（软件仓库），即为存放于本地特定位置的众多rpm包建立索引，描述各包所需依赖信息，并形成元数据。也就是这个createrepo在Windows下不太可能存在。如果这个不存在的话是没有办法经过判断的。既然服务器内不存在createrepo，那就想办法创建一个，我首先试的是找个上传点，尝试上传一个createrepo，但是没找到上传之后名字还能保持不变的点。在Artifacts Upload处上传之后，都变成Artifact-Version.Packaging这种形式的名字了，Artifact-Version.Packaging这个是不满足第二个判断的，得以createrepo结尾。

一开始看到file.exists()就走进了思维定势，以为是判断文件存在的，但是看了官方的文档，发现是判断文件或者目录存在的。。这点也就是这个漏洞形成的第二个关键点，我不能创建文件，但是可以创建文件夹啊。在Artifacts Upload上传Artifacts 的时候，可以通过GAV Parameters来定义。

当Group设置为test123，Artifact设置为test123，Version设置成1，当上传Artifacts的时候，是会在服务器中创建对应的目录的。对应的结构如下

如果我们将Group设置为createrepo，那么就会创建对应的createrepo目录。

结合两个特性来测试一下

String cmd = "C:\\Windows\\System32\\calc.exe \\..\\..\\..\\nexus\\sonatype-work\\nexus\\storage\\thirdparty\\createrepo";File file = new File(cmd);System.out.println(file.exists());System.out.println(file.getName());System.out.println(file.getAbsolutePath());

可以看到，file.exists()返回了true，file.getName()返回了createrepo，都符合判断了。

最后到getRuntime()里面大概就是getRuntime.exec({"C:\Windows\System32\notepad.exe","\..\..\..\nexus\sonatype-work\nexus\storage\thirdparty\createrepo","--version"})

是可以成功执行notepad.exe的。(calc.exe演示看不到进程哈，所以换成Notepad.exe)