【最新漏洞預警】Zoho ManageEngine Admanager Plus 任意文件上傳漏洞可GetShell - 網安

漏洞信息

2021年9月，Zoho官方通報了Zoho ManageEngine ADManager Plus的多個漏洞：

包括：

CVE-2021-37539CVE-2021-37762CVE-2021-37741CVE-2021-37761CVE-2021-37925CVE-2021-37919CVE-2021-37920CVE-2021-37921CVE-2021-37923CVE-2021-37924CVE-2021-37918CVE-2021-37922CVE-2021-37931CVE-2021-37930CVE-2021-37929CVE-2021-37928CVE-2021-37926

這些漏洞以文件上傳類型為主，影響v7111及以下版本。其實這個產品和前期分析的Zoho ManageEngine ADSelfService Plus有很多類似的代碼，相關文章鏈接如下：

CVE-2021-40539

QCyber，公眾號：且聽安全CVE-2021-40539-Zoho ManageEngine ADSelfService Plus如何從bypass到RCE

下面將Zoho Manageengine Admanager Plus其中一處認證后的任意文件上傳漏洞分享給大家。

進程分析

系統使用Tomcat容器進行構建，查看服務配置：

8080端口對應`ADMP`服務，找到對應進程并獲取啟動命令：

加入調試信息并重啟，成功打開遠程調試端口：

數據庫分析

在`bin`目錄有一個連接數據庫腳本`connectDB.bat`：

cd ../pgsql/binclspsql -h127.0.0.1 -Uadmanager -p33306 -dadsm

默認情況下數據庫配置信息位于`database_params.conf`：

利用上面的配置信息，成功連接數據庫：

合法API URL分析

查看`web.xml`，找到一個名為`FWServletAPI`的`servlet`：

同時定義了多個針對全部URL請求的過濾器，比如`ADSFilter`:

我們隨意構造一個URL請求：

http://***:8080/RestAPI/WC/NotificationTemplate/test

在`ADSFilter#doFilter`打下斷點：

進入`doSubFilters`：

經過一系列參數提取和身份認證驗證后，第136行調用函數`RestAPIUtil.isRestAPIRequest`來驗證URL：

然后調用`RestAPIFilter.doAction`：

第61行通過`RestAPIUtil.getAPIDetails`來獲取API接口的信息，跟進：

發現這里是從數據庫中來尋找合法的API URL規則：

一共有607個合法URL規則：

尋找`/RestAPI/WC/NotificationTemplate/*`合法的URL列表，共計13個：

/RestAPI/WC/NotificationTemplate/getDefaults/RestAPI/WC/NotificationTemplate/getTemplate/RestAPI/WC/NotificationTemplate/saveTemplate/RestAPI/WC/NotificationTemplate/deleteTemplates/RestAPI/WC/NotificationTemplate/copySettings/RestAPI/WC/NotificationTemplate/attachFiles/RestAPI/WC/NotificationTemplate/removeFileAttachment/RestAPI/WC/NotificationTemplate/getShareSettings/RestAPI/WC/NotificationTemplate/saveShareSettings/RestAPI/WC/NotificationTemplate/getShareableUsers/RestAPI/WC/NotificationTemplate/getModuleDetails/RestAPI/WC/NotificationTemplate/getTemplates/RestAPI/WC/NotificationTemplate/addRemoveColumns

相關定義位于文件`ADSProductAPIs_OMP.xml`：

文件上傳

既然漏洞與文件上傳有關，重點關注名為`attachFiles`的URL，替換HTTP請求為：

/RestAPI/WC/NotificationTemplate/attachFiles

定位函數`attachFiles`：

提取請求的相關參數后沒有進行任何檢查，直接將上傳的文件內容進行寫入操作。構造如下請求：

直接GetShell：

修復方式

v7111版本中函數`attachFiles`中增加了對文件后綴名的判斷：

文件后綴名判定通過新增的`FileUtil.validateImageFileExtension`函數完成：

將文件類型限制為：

public static final String DEFAULT_IMAGE_EXTENSION[] = {    "jpg", "png", "gif", "jpeg", "tiff", "pjp", "pjpeg", "jfif", "tif", "svg",     "bmp", "svgz", "webp", "ico", "xbm", "dib"};

寫在最后

通過補丁對比發現還存在多處文件上傳漏洞的修復，比如`com.manageengine.ads.fw.ssl.SSLAPI#addNewCertificate`：

同樣對文件后綴進行了過濾，通過研究發現這個觸發點是對壓縮包進行解壓，但是沒有對文件后綴進行檢查，可以實現任意文件上傳，但是在處理完壓縮包后，程序會自動刪除文件，但是存在條件競爭的問題，仍可GetShell。

再比如`com.manageengine.ads.fw.sso.ADSSAMLAPI#saveSAMLConfig`：

也是增加后綴名檢查，還有一些其他點在原理上也是相同的，這里就不一一贅述了，有興趣的小伙伴可自行研究。