ZOHO ManageEngine OpManager 两个RCE
前言
最近在审计opmanager，正好爆了rce来学习一下
第一个RCE（CVE-2022-37024）
环境直接官网下载，一路下一步即可
漏洞描述是：允许经过身份验证的用户进行数据库更改，从而导致NMAP功能中的远程代码执行。也就是说可以分为两点一是：如何修改数据库的内容。二是：找执行nmap操作时从数据库中提取并拼接的参数
报着这样的想法先来看一波补丁，这里用的是125657和125658，在com.adventnet.netutils.fw.nmap.utils.NmapUtil#getNmapInitialOption中删除了一个ADDITIONAL_COMMAND字段，该字段进入到IPAMUseBean.getIPAMPropertyString(keys)中从数据库IPAMProperty的表中取出value值，然后返回拼接到nmap中返回一串字符串，而且从该函数的名字就可以看出初始化nmap参数，到这里猜测八九不离十了
接着就去找执行nmap命令的函数，在com.adventnet.netutils.fw.nmap.utils.NmapCmdExecutor#runNmapCommand中找到了函数，先打个断点方便一会调试，这里标记了一下envs.put("PATH", path)，是一个坑，这里设置了一下PATH环境变量导致了在执行命令时必须加上绝对路径比如：C:\Windows\System32\calc.exe才能够执行命令
然后就又找了一会sql注入（修改数据库内容，第一眼看见就以为是sql注入实际上并不是），没找到就去测功能点看是不是在功能点中能传入数据，也没找到（全都是ip一类的而且做了正则），到这里又换个思路先去测试一下那个功能点能够触发先前找的runNmapCommand函数（万一一开始就找错了呢）
分别在拼接ADDITIONAL_COMMAND和最后执行start()时打上断点，在测试网络扫描器时分别先后触发，这样看来思路没错，接下来就是去找怎么修改ADDITIONAL_COMMAND的值
就继续翻补丁，在com.adventnet.netutils.networkmgmt.IPAddressManagerActionForwarder#updateGeneralSettings中，找到了对DNS_SERVER参数进行了过滤，然后执行了sql操作，这里就想着sql注入改ADDITIONAL_COMMAND的值在通过功能去触发nmap到最后执行命令（此时脑子就有点懵没仔细看表，其实两张表不同而且并不能堆叠注入直接修改），有目标了就接着就往上回溯在com.adventnet.netutils.api.admin.AdminRequestHandler#updateIPAMSettings中找到了触发点
看到接收的请求是request，就想是不是servlet但是没有继承httpservlet，那么就有可能是其它路由转发，这样的话就不是很好找了，到这里没有思路了，就只能笨办法打断点功能点一个一个点，找了一会没有触发，这时候Y4er师傅闪亮登场亲手调试了一番，发现了这个点并不能修改ADDITIONAL_COMMAND的值，也就是一开始找的数据库的点就错了，然后就继续找在com.adventnet.netutils.fw.nmap.utils.NmapUtil#getDNSResolveOption中找到了这个点，从数据库拿出DNS_SERVER的值，然后返回值最后拼接到nmap语句中（一开始我以为是修复了sql注入的点，还是自己经验不太够），那么修复ADDITIONAL_COMMAND应该单纯就是为了防止也像DNS_SERVER一样，但是更彻底直接给删了
接下来就是找DNS_SERVER注入的点，全局搜索到了updateIPAMSettings类的路由，接着直接根据给定的param构造数据包，成功将C:\Windows\System32\calc.exe传了进去
接着打断点调试，成功拼接
然后尝试传入& |等尝试执行命令，但是在执行nmap操作前DNS_SERVER会先经过两次过滤，分别是插入数据库前和拼接到nmap命令前，先经过以下正则匹配传入数据库，在将所有空白字符替换，最后才拼接到nmap中，到这里一直绕不过限制执行命令
另一个RCE（CVE-2022-38772）
当我看见另一个rce漏洞描述的时候，人其实是懵的，所以ADDITIONAL_COMMAND也是可以和DNS_SERVER一样拼接到nmap操作里，触发命令注入的，那么当时没找到肯定就是漏了一个重要的关键点，因此我就又一个一个将补丁看了一下，果然发现了两个点：一个是com.adventnet.netutils.api.ipam.IPAMAPIUtil#configureNmapScanOptions里，另外一个是在com.adventnet.ncm.api.impl.SettingsRESTApiModule#executeDBQueryConsole中
先来看第一个，删了ADDITIONAL_COMMAND，并且删除了从request提取ADDITIONAL_COMMAND的操作，那么这个应该是可以从api直接访问并且构造恶意包内容的
接着全局搜索找到了相应路由和参数，但是配置文件里没有配置ADDITIONAL_COMMAND参数，构造数据包测试一下果然报错，找了一下没有办法绕过
然后就继续翻补丁，找到了一个执行sql操作的地方，从request中提出QUERY_STRING的值，然后传入到RunQuery中执行sql操作，这里做了校验只是从QUERY_STRING中取出前6个字符判断不能为：insert、delete、drop，其中并没有限制update那么可以直接修改DNS_SERVER的值从而绕过第一次正则匹配，但是不能绕过空白字符替换，另外也可以通过;绕过其限制，直接插入ADDITIONAL_COMMAND的值
全局搜索找到调用executeDBQueryConsole的路由，而且QUERY_STRING没有校验，那么直接构造数据包向IPAMProperty表中插入数据
这里直接插入时提示最大长度为100，那么就先随便插入在通过update修改值即可
最后来看一下执行nmap时，拼接的参数
还有另外一个路由/api/json/ipam/addDHCPServer也可以触发nmap操作，但是依然不能够结合apikey达到未授权rce的效果
小结
opmanager前段时间还爆了一个获取apikey的洞，文章在这，但是这个apikey并不能调用这几个路由，因此少了一环没有能够未授权rce，但是/api/json/ncmsettings/executeDBQuery可以通过apikey调用可以执行sql操作，这次审漏洞收获不少，多了许多的思路能够运用到以后的挖洞中，也有不足，经验不够还要多审计提升经验