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那里可以上传任意文件的地方依然还在，如果其他地方再出现上面的情况依然可以利用到。