OMSA文件讀取漏洞CVE-2020-5377的示例分析

小編給大家分享一下OMSA文件讀取漏洞CVE-2020-5377的示例分析，希望大家閱讀完這篇文章之后都有所收獲，下面讓我們一起去探討吧！

OpenManage Server Administrator（OMSA）是什么？

根據OMSA的官方文檔描述：

“OpenManage Server Administrator（OMSA）是一個軟件代理，它通過兩種方式提供全面的一對一系統管理解決方案：即基于Web瀏覽器的圖形用戶接口，以及操作系統端的命令行接口。”

換句話說，OMSA可以幫助開發人員對安裝了OMSA的服務器進行中央監控。OMSA還支持通過中央Web接口和分布式Web服務器（DWS），以及“管理系統登錄”功能來管理遠程系統。

OMSA中的身份認證繞過

為了簡要概述繞過身份驗證的工作方式，OMSA提供了使用中央服務器登錄遠程系統的功能，以便利用分布式Web服務器（DWS）并通過單個Web界面對遠程系統進行管理。默認配置下系統會自動啟用該功能。

接下來，我們就可以通過托管一個惡意遠程節點來繞過身份驗證，該節點響應來自OMSA服務器的身份驗證請求并驗證登錄，從而導致OMSA服務器為用戶發出一個Web會話。這個Web會話僅用于在集中式Web界面中呈現來自遠程節點的內容。但是，我們發現在OMSA的9.4.0.0和9.4.0.2版本中，此會話將允許用戶對底層API進行特權訪問。

下圖顯示的是設置界面中管理系統登錄功能的開啟和關閉：

下圖顯示的是OMSA身份認證繞過步驟的流程圖：

在第四步中，服務器會發送一個JSESSIONID cookie和一個VID，并授權一個特權會話發送給OMSA Web接口，接下來我們就可以用它直接向OMSA服務器發出后續的特權API請求。

文件讀取漏洞細節

OMSA Web接口使用的是Apache Tomcat，通過分析web.xml，我們會發現身份認證servlet會暴露在/DownloadServlet：

<servlet><servlet-name>DownloadServlet</servlet-name><servlet-class>com.dell.oma.servlet.secure.DownloadServlet</servlet-class></servlet>

反編譯OMSA.jar文件并分析類文件后，我們發現了一個明顯的文件讀取漏洞：

string str1 = paramHttpServletRequest.getParameter("file");

<SNIP ----->

File file = new File(str1);

    if (false == oMAWPUtil.checkUserRights(paramHttpServletRequest, 7)) {

      String str4 = file.getCanonicalPath();

      String str5 = "apache-tomcat" + File.separator + "temp";

      OMALogging.getInstance().write(9, "DownloadServlet : Canonical path :" + str4);

      if (!str4.contains(str5)) {

        OMALogging.getInstance().write(9, "DownloadServlet : access denied to file :" + str1);

        return;

      }

    }

 

<SNIP--->

 

    FileInputStream fileInputStream = null;

    String str3 = getServletContext().getMimeType(str1);

    paramHttpServletResponse.setContentType(str3);

    paramHttpServletResponse.setHeader("Content-Disposition", "attachment; filename=\"" + str2 + "\";");

    paramHttpServletResponse.setContentLength((int)file.length());

    ServletOutputStream servletOutputStream = paramHttpServletResponse.getOutputStream();

    try {

      fileInputStream = new FileInputStream(str1);

      int j = 0;

      while ((j = fileInputStream.read()) != -1)

        servletOutputStream.write(j);

}

我們可以看到，“file”這個GET參數被設置為了“str1”，并被傳遞給了FileInputStream，然后讀取進了應用程序的響應之中。這里唯一的檢測就是我們Web會話的“用戶權限”為“7”，這也是通過身份認證繞過獲取到的會話所滿足的條件，這將允許我們在目標文件系統上讀取任何我們想要的路徑。

存在漏洞的請求如下：

https://omsa.server/{VID}/DownloadServlet?help=Certificate&app=oma&vid={VID}&file=C:\some\file

戴爾漏洞CVE-2021-21514：安全過濾器繞過

CVE-2020-5377漏洞修復后，開發人員引入了一個安全過濾器，目的就是為了保護DownloadServlet這個servlet免受任意文件讀取漏洞的影響，但并沒有什么效果。

調用DownloadServlet時，程序會使用過濾器查找傳遞到DownloadServlet的惡意路徑，惡意請求將會被拒絕。

過濾器如下：

<filter-name>PathManipulationFilter</filter-name>

<filter-class>security.web.PathManipulationFilter</filter-class>

相關的反編譯類代碼段如下：

public static boolean isFileHandlerRequest(String paramString) {

    boolean bool = false;

    Set<String> set = a.keySet();

    Iterator<String> iterator = set.iterator();

    String str = null;

    while (iterator.hasNext()) {

      str = iterator.next();

      if (StringUtil.trim(paramString).contains(str)) {

        bool = true;

        break;

      }

    }

    return bool;

  }

 

<SNIP>

 static {

    a = new HashMap<>();

    HashMap<Object, Object> hashMap1 = new HashMap<>();

    hashMap1.put("file_1", "oma_\\d+.(log|html|zip)$");

    hashMap1.put("file_2", "\\.*(\\.cer|\\.CER)$");

    a.put("DownloadServlet", hashMap1);

    HashMap<Object, Object> hashMap2 = new HashMap<>();

    hashMap2.put("file_1", ".*");

    a.put("UploadServlet", hashMap2);

    HashMap<Object, Object> hashMap3 = new HashMap<>();

    hashMap3.put("file_1", ".*");

    a.put("UploadCertServlet", hashMap3);

    HashMap<Object, Object> hashMap4 = new HashMap<>();

    hashMap4.put("path_1", "(\\\\|\\/)(oma|upload)(\\\\|\\/)\\d+");

    hashMap4.put("path_2", "(\\\\|\\/)temp");

    a.put("ViewFile", hashMap4);

  }

上面的代碼顯示了過濾器代碼的一個片段，每個請求的URL都會被傳遞給isFileHandlerRequest方法，以測試URL是否包含HashMap “a”中列出的任何字符串。由于“a”只包含文本字符串，因此不用考慮任何類型的編碼。只需對URL路徑的一部分進行URL編碼，即可完全繞過此過濾器，從而導致isFileHandlerRequest方法返回false。

現在的URL如下：

https://omsa.server/{VID}/DownloadServle%74?help=Certificate&app=oma&vid={VID}&file=C:\some\file

其中的t被URL編碼后為%74，請求將成功。

漏洞概念驗證PoC

為了驗證漏洞的有效性，我們創建了一個【漏洞利用PoC】，其中包含一個有效的會話Cookie，并且可以使用這個會話從服務器端讀取一個文件。

漏洞緩解

為此，戴爾還是發布了一個漏洞修復方案。但是，們確定使用遠程管理登錄繞過身份驗證是預期的功能。這也就意味著，即使在安裝了修復補丁之后，我們仍然可以使用本文所介紹的身份認證人熬過漏洞來獲得API的有效會話cookie。如果你不需要使用遠程管理登錄功能的話，則應該禁用該功能以消除相關攻擊面。

我們可以通過以下步驟禁用托管系統登錄功能：

在登錄屏幕上，單擊“管理Web服務器”；

使用系統管理員憑據進行登錄；

單擊“首選項”；

將“管理系統登錄”切換為“禁用”；

總結

利用這種身份認證繞過技術，將為我們提供很多的可能性，比如說利用API來實現一些惡意操作等等，例如本文所介紹的任意文件讀取。

一旦獲得了有效的會話cookie，就可以訪問其他危險的功能。因此，如果您不使用OMSA Web界面訪問遠程系統，我們強烈建議您禁用“托管系統登錄”功能。如果您根本不使用OMSA，則應完全卸載或禁用該服務。如果它正在使用中，當然，我們建議廣大用戶保持運行OMSA的最新版本，或安裝最新的漏洞修復補丁。

看完了這篇文章，相信你對“OMSA文件讀取漏洞CVE-2020-5377的示例分析”有了一定的了解，如果想了解更多相關知識，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！