作者: 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系统执行命令了。但是有一个很大的限制：
- nexus需要安装在系统盘
- 一些带参数的命令无法使用
在上面说到的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那里可以上传任意文件的地方依然还在，如果其他地方再出现上面的情况依然可以利用到。
