Nexus Repository Manager 2.x 命令注入漏洞 (CVE-2019-5475) 两次绕过

作者: Badcode and LonGofo@知道创宇404实验室 

时间: 2020年2月9日

原文链接:https://paper.seebug.org/1260/

英文链接:https://paper.seebug.org/1261/

前言

2019年9月初我们应急了Nexus Repository Manager 2.x 命令注入漏洞(CVE-2019-5475)，其大致的原因和复现步骤在 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 之后变成了cmd.exe \c whoami，后面是执行不了的。可以直接执行exe，注意后面是还会拼接--version的，所以很多命令是执行不了的，但是还是有办法利用能执行任意exe这点来做后续的攻击的。

第二次绕过分析

第二次补丁分析

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

在getCleanCommand() C:\\windows\\System32\\calc.exe \\..\\..\\win.ini

经过parse()第二次绕过测试

测试环境

• 2.14.15-01 版本
• Windows

测试步骤

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

查看进程，notepad.exe启动了

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

第二次绕过分析+

经过Badcode师傅第二次绕过分析，可以看到能成功在Windows系统执行命令了。但是有一个很大的限制：

1. nexus需要安装在系统盘
2. 一些带参数的命令无法使用

在上面说到的Artifacts Upload上传处是可以上传任意文件的，并且上传后的文件名都是通过自定义的参数拼接得到，所以都能猜到。那么可以上传自己编写的任意exe文件了。

第二次绕过分析+测试

测试环境

• 2.14.15-01 版本
• Windows

测试步骤

导航到Views/Repositories->Repositories->3rd party->Configuration，我们可以看到默认本地存储位置的绝对路径（之后上传的内容也在这个目录下）：

导航到Views/Repositories->Repositories->3rd party->Artifact Upload，我们可以上传恶意的exe文件：

该exe文件将被重命名为createrepo-1.exe（自定义的参数拼接的）：

同样在Path of "createrepo"里面传入 payload（这时需要注意前面部分这时是以nexus安装目录开头的，这在补丁中会判断，所以这里可以在最顶层加..\或者弄个虚假层aaa\..\等）

可以看到createrepo-1.exe已经执行了：

最新版本分析

最新版本补丁分析

第二次补丁绕过之后，官方又进行了修复，官方补丁主要如下

删除了之前的修复方式，增加了YumCapabilityUpdateValidator类，在validate中将获取的值与properties中设置的值使用equals进行绝对相等验证。这个值要修改只能通过sonatype-work/nexus/conf/capabilities.xml

最新版本验证

前端直接禁止修改了，通过抓包修改测试：

在YumCapabilityUpdateValidator.validate断到

可以看到这种修复方式无法再绕过了，除非有文件覆盖的地方覆盖配置文件，例如解压覆盖那种方式，不过没找到。

不过Artifacts Upload那里可以上传任意文件的地方依然还在，如果其他地方再出现上面的情况依然可以利用到。