2020年3月6日,有安全研究人员 steventseeley
在Twitter上发布了Zoho企业产品 Zoho ManageEngine Desktop Central
中的反序列化远程代码执行漏洞.利用该漏洞可直接控制安装该产品的服务器,该产品为Windows系统上运行的一种端点管理解决方案,客户可用它管理网络中的设备,例如:Android手机,Unix服务器以及Windows工作站等.它往往充当公司内部的中央服务器,帮助系统管理员推送更新,远程控制系统,锁定设备,控制访问权限等。
Zoho ManageEngine Desktop Central < 10.0.479
CVE-2020-10189
高危
我们进入 DesktopCentral_Server/webapps/DesktopCentral/WEB-INF/
目录提取 web.xml
,可以看到一个名为 CewolfServlet
的 servlet
.
该 servlet
对应的 class
为 de.laures.cewolf.CewolfRenderer
,该类存在于 DesktopCentral_Server/lib/cewolf-1.2.4.jar
该类中的get方法使用 img
参数接受 imgKey
的值
imgKey将会被 Storage
类中的 getChartImage
方法调用
在该jar包中存在一个 FileStorage
类基于 Storage
类实现接口的类.在其内部存在一个 storeChartImage
方法,该方法直接将接收到的文件流存储在本地.该方法内部调用一个 getFileName
类用于拼接base路径.
在查看 storeChartImage
方法的同时,我注意到还有一个获取文件的方法 getChartImage
.
清晰可见的是它执行了一个非常危险的操作,直接让 ObjectInputStream
执行了 readObject
方法.可见这就是漏洞的触发点.那么问题来了,有了反序列化的点,序列化文件的点从哪里来?
于是我再次检索 web.xml
,发现了一个具有上传功能的 servlet
.
该 servlet
对应 DesktopCentral_Server/lib/AdventNetDesktopCentral.jar
中的 com.me.mdm.agent.servlets.file.MDMFileUploaderServlet
.
在该类中存在 Post
方法,可见 udid
和 filename
为可控点,我们完全可以自己传值控制.当然 udid
其实也做了三种安全检查,但并不影响目录穿越的产生.
而 filename
被做了后缀名限制,只允许为 log|txt|zip|7z
其中一种
其实在 security-mdm-agent.xml
做了进一步限制
只允许完整文件名称为 logger.txt|logger.zip|mdmlogs.zip|managedprofile_mdmlogs.zip
.不过这丝毫不影响我们上传恶意的序列化文件.
我们进入 DesktopCentral_Serverlib
目录,寻找有漏洞的jar.
可见我们发现了 commons-collections.jar
、 commons-beanutils-1.8.0.jar
commons-collections.jar
不确定具体版本,我们查看一下版本
太完美了它是 commons-collections:3.1
.可见我们可以利用 CommonsBeanutils1
和 CommonsCollections3
两条gagdets.当然还有jdk的两条gagdets, JDK7U21
和 JRE8U20
.
我们请出反序列化文件构建神器—— ysoserial
.
我们使用 ysoserial
中的两条gadgets构建序列化文件即可.但是这里我们需要注意的是如果直接使用可能会反序列化失败,
这是由于我们在打包 ysoserial
时默认的依赖版本是 1.9.2
,而 Zoho ManageEngine Desktop Central
自带的是 commons-beanutils-1.8.0
,这将导致 UID
不同,从而造成反序列化失败.我们只需要修改 ysoserial
的 pom.xml
中的 commons-beanutils
为1.8系列即可
为了满足漏洞管理条例,本文不直接放出payload,可自行参考文末的公开payload
https://nosec.org/home/detail/4211.html
https://srcincite.io/pocs/src-2020-0011.py.txt
https://nvd.nist.gov/vuln/detail/CVE-2020-10189