【最新漏洞预警】认证绕过新姿势之Zoho ManageEngine Desktop Central CVE-2021-44515

关注公众号回复“漏洞”获取研究环境或工具

继续卷Zoho！前期公众号给小伙伴分享的Zoho系列漏洞如下：

【最新漏洞预警】CVE-2021-41081-通过逆向推理快速分析Zoho ManageEngine NCM SQL注入漏洞

QCyber，公众号：且听安全【最新漏洞预警】CVE-2021-41081-通过逆向推理快速分析Zoho ManageEngine NCM SQL注入漏洞

【最新漏洞预警】CVE-2021-44077 Zoho ManageEngine ServiceDesk Plus RCE漏洞

QCyber，公众号：且听安全【最新漏洞预警】CVE-2021-44077 Zoho ManageEngine ServiceDesk Plus RCE漏洞

Zoho ManageEngine Admanager Plus 任意文件上传漏洞可GetShell

QCyber，公众号：且听安全【最新漏洞预警】Zoho ManageEngine Admanager Plus 任意文件上传漏洞可GetShell

Zoho ManageEngine ADSelfService Plus如何从bypass到RCE

QCyber，公众号：且听安全CVE-2021-40539-Zoho ManageEngine ADSelfService Plus如何从bypass到RCE

如何绕过反序列化漏洞补丁-Zoho ManageEngine OpManager

QCyber，公众号：且听安全CVE-2020-28653-如何绕过反序列化漏洞补丁-Zoho ManageEngine OpManager

最近看网上有人分析了CVE-2021-44515漏洞，参考链接如下：

CVE-2021-44515 Zoho ManageEngine Desktop Central Pre-auth RCE

https://xz.aliyun.com/t/10638

影响Zoho manageEngine Desktop Central的`101213702`版本，自己也跟进分析了下，发现还存在其他不同的认证绕过方式，可惜这种新的绕过方式在`101213703`中也一并被修复了，这里就分享给大家吧。

环境部署就不多说了，不了解的小伙伴可以参考公众号以前的文章。在公开文章中，提到的认证绕过缺陷存在于`XSSFilter#doFilter`中，通过构造特殊URL可以绕过`SecurityFilter#doFilter`。自己在补丁对比后，发现还存在一个认证绕过的点。在版本对比分析时，初一看没有发现特别敏感的变动，但是在`web.xml`发现一处非常隐蔽的修改：

添加了对`/STATE_ID/*`的访问限制，查看定义：

在`StateFilter`和`DemoFilter`打下断点，构造如下请求：

http://****:8020/STATE_ID/aaa

`DemoFilter`过滤器没有实质的处理过程，顺利进入到`StateFilter`，此时调用栈如下：

没有进行认证处理，也就是说目前可以未授权到达`StateFilter#doFilter`:

如上图所示，这里的处理代码很有意思，因为访问路径中包含`STATE_ID`，所以请求肯定进入`else`分支，从而跳过了剩余的Filter过滤处理，这里显然存在认证绕过的可能性。但是上面的访问在经过第38行`StateParserGenerator.processState`处理时会抛出异常，要想办法解决掉这个异常，进入函数：

提取Cookie信息，如果为空将抛出异常。继续往下看，定义了一个`TreeSet`类型的变量`set`，遍历Cookie：

所以请求Cookie中可以加上`STATE_COOKIE`，继续往下走：

第265行调用函数`parseState`获取`Map`类型的参数`state`，紧接着在第275行通过`state`设置`StateAPI.prevStateDataRef`，后面分别会从URL中提取`long`类型参数`urlTime`和`reqTime`，先看下`getTimeFromUrl`函数：

请求URL应该修改成下面的格式：

http://****:8020/STATE_ID/[long]/...
Cookie:STATE_COOKIE=aaa

回到`StateParserGenerator.processState`，第279行进入函数`StateAPI.getRequestState`：

因为`StateAPI.prevStateDataRef`来源于`state`，为了使其值不为`null`，需要修改`state`的格式，从上面分析可知，`state`格式如下：

{"_REQS":{"_TIME":"***"}}

回顾参数`state`通过函数`parseState`的赋值过程：

通过`&`、`/`对Cookie进行分割生成`stateArray`，然后进入for循环给map变量赋值，为了符合`state`格式，需要修改Cookie格式，然后继续调试：

回到`StateFilter#doFilter`函数，顺利解决了`StateParserGenerator.processState`会抛出异常的问题，进入`else`分支：

函数`getForwardPath`会提取`/STATE_ID/[long]`之后的路径：

然后直接转发给对应的`servlet`进行处理，由于`else`分支没有执行`chain.doFilter`，所以可以跳过后面所有的`Filter`，从而实现认证绕过。

以`DCRequestHandler`为例：

正常访问需要认证：

绕过认证：

在未认证的条件下成功进入`com.me.dconpremise.webclient.sdp.DCRequestHandler#doGet`函数。

https://xz.aliyun.com/t/10638

由于传播、利用此文档提供的信息而造成任何直接或间接的后果及损害，均由使用本人负责，且听安全团队及文章作者不为此承担任何责任。

点关注，不迷路！

关注公众号回复“漏洞”获取研究环境或工具