您好,登录后才能下订单哦!
作者: Badcode and Longofo@知道创宇404实验室
时间: 2020年2月9日
原文链接: https://paper.seebug.org/1260/
英文链接: https://paper.seebug.org/1261/
在上面
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()
方法,对命令进行过滤。
在我提交上述绕过方式后,官方修复了这种绕过方式,看下官方的 补丁
经过
parse()
第二次绕过测试
在
Path of "createrepo"
里面传入 payload。
查看进程,
notepad.exe
启动了
可以看到,成功绕过了补丁。
经过Badcode师傅第二次绕过分析,可以看到能成功在Windows系统执行命令了。但是有一个很大的限制:
在上面说到的
Artifacts Upload
上传处是可以上传任意文件的,并且上传后的文件名都是通过自定义的参数拼接得到,所以都能猜到。那么可以上传自己编写的任意exe文件了。
导航到
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
那里可以上传任意文件的地方依然还在,如果其他地方再出现上面的情况依然可以利用到。
亿速云「云服务器」,即开即用、新一代英特尔至强铂金CPU、三副本存储NVMe SSD云盘,价格低至29元/月。点击查看>>
开发者交流群:
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。
原文链接:http://blog.itpub.net/69912109/viewspace-2701631/