Shulou(Shulou.com)05/31 Report--

Editor to share with you the example analysis of OMSA file reading vulnerability CVE-2020-5377. I hope you will get something after reading this article. Let's discuss it together.

What is OpenManage Server Administrator (OMSA)?

According to the official documentation of OMSA:

"OpenManage Server Administrator (OMSA) is a software agent that provides a comprehensive one-to-one system management solution in two ways: a Web browser-based graphical user interface and an operating system-side command line interface."

In other words, OMSA can help developers centrally monitor servers with OMSA installed. OMSA also supports the management of remote systems through a central Web interface and a distributed Web server (DWS), as well as the manage system login function.

Authentication Bypass in OMSA

To provide a brief overview of how authentication bypasses authentication, OMSA provides the ability to log in to a remote system using a central server to leverage a distributed Web server (DWS) and manage the remote system through a single Web interface. This feature is automatically enabled by the default configuration.

Next, we can bypass authentication by hosting a malicious remote node that responds to an authentication request from the OMSA server and verifies the login, causing the OMSA server to issue a Web session for the user. This Web session is only used to render content from remote nodes in a centralized Web interface. However, we found that in versions 9.4.0.0 and 9.4.0.2 of OMSA, this session will allow users privileged access to the underlying API.

The following figure shows the switch on and off of the manage system login function in the settings interface:

The following figure shows a flowchart of OMSA authentication bypass steps:

In step 4, the server sends a JSESSIONID cookie and a VID and authorizes a privileged session to send to the OMSA Web interface, which we can then use to make subsequent privileged API requests directly to the OMSA server.

Details of file reading vulnerabilities

The OMSA Web interface uses Apache Tomcat. By analyzing the web.xml, we will find that the authentication servlet will be exposed in / DownloadServlet:

DownloadServletcom.dell.oma.servlet.secure.DownloadServlet

After decompiling the OMSA.jar file and analyzing the class file, we found an obvious file reading vulnerability:

String str1 = paramHttpServletRequest.getParameter ("file"); 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;}} 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);}

We can see that the GET parameter "file" is set to "str1" and passed to FileInputStream, which is then read into the application's response. The only check here is that the "user rights" of our Web session is "7", which is also a condition for the session obtained by authentication bypass, which will allow us to read any path we want on the target file system.

The requests with vulnerabilities are as follows:

Https://omsa.server/{VID}/DownloadServlet?help=Certificate&app=oma&vid={VID}&file=C:\some\file Dell vulnerability CVE-2021-21514: security filter Bypass

After the CVE-2020-5377 vulnerability was fixed, developers introduced a security filter to protect the DownloadServlet servlet from arbitrary file read vulnerabilities, but to no avail.

When calling DownloadServlet, the program will use a filter to find the malicious path passed to the DownloadServlet, and the malicious request will be rejected.

The filters are as follows:

PathManipulationFiltersecurity.web.PathManipulationFilter

The related decompiled class code snippets are as follows:

Public static boolean isFileHandlerRequest (String paramString) {boolean bool = false; Set set = a.keySet (); Iterator iterator = set.iterator (); String str = null; while (iterator.hasNext ()) {str = iterator.next (); if (StringUtil.trim (paramString). Return bool; (str)) {bool = true; break;} return bool;} static {a = new HashMap () HashMap hashMap1 = new HashMap (); hashMap1.put ("file_1", "oma_\\ zip. (log | html | zip) $"); hashMap1.put ("file_2", "\\ .cer |\\ .CER) $"); a.put ("DownloadServlet", hashMap1); HashMap hashMap2 = new HashMap (); hashMap2.put ("file_1", ". *"); a.put ("UploadServlet", hashMap2) HashMap hashMap3 = new HashMap (); hashMap3.put ("file_1", ". *"); a.put ("UploadCertServlet", hashMap3); HashMap hashMap4 = new HashMap (); hashMap4.put ("path_1", "(\ |\\ /) (oma | upload) (\ |\\ /)\\ d+"); hashMap4.put ("path_2", "(\ |\ /) temp") A.put ("ViewFile", hashMap4);

The above code shows a snippet of the filter code, and the URL of each request is passed to the isFileHandlerRequest method to test whether the URL contains any of the strings listed in HashMap "a". Because "a" contains only text strings, you don't have to worry about any type of encoding. This filter can be completely bypassed by URL encoding a portion of the URL path, causing the isFileHandlerRequest method to return false.

The current URL is as follows:

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

Where t is encoded by URL to% 74, the request will be successful.

Vulnerability proof of concept PoC

To verify the validity of the vulnerability, we created a [exploit PoC] that contains a valid session Cookie, and you can use this session to read a file from the server.

Loophole mitigation

To this end, Dell has released a bug fix. However, we determined that using remote administrative login to bypass authentication is the expected feature. This means that even after the fix is installed, we can still use the identity witness described in this article to get through the vulnerability to get a valid session cookie for API. If you do not need to use the remote administrative login feature, you should disable it to eliminate the attack surface.

We can disable the managed system login feature by following these steps:

On the login screen, click manage Web Server

Log in with system administrator credentials

Click preferences

Switch from manage system login to disabled

Summary

Using this authentication bypass technology will provide us with many possibilities, such as using API to achieve some malicious operations and so on, such as arbitrary file reading introduced in this article.

Once you have a valid session cookie, you can access other dangerous functions. Therefore, if you do not use the OMSA Web interface to access remote systems, we strongly recommend that you disable the managed system login feature. If you do not use OMSA at all, you should uninstall or disable the service completely. If it is in use, of course, we recommend that users keep running the latest version of OMSA or install the latest bug fixes.

After reading this article, I believe you have some understanding of "sample Analysis of OMSA File Reading vulnerability CVE-2020-5377". If you want to know more about it, you are welcome to follow the industry information channel. Thank you for your reading!

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.