Introduction to Dell Exploit: CVE-2020-5377
This blog explores a file read vulnerability in Dell OpenManage Server Administrator (OMSA) we found during an internal network penetration test, tracked as CVE-2020-5377 and a bypass for the fix tracked as CVE-2021-21514.
When this Dell vulnerability is leveraged along with an authentication bypass, based on great research by Harrison Neal here, it allows unauthenticated arbitrary file read, confirmed in OMSA version 9.4.0.0 and 9.4.0.2.
In addition, during the discovery of these vulnerabilities it was found that the arbitrary file read disclosed back in 2016 here, still affected the most recent version of OMSA, 9.4.0.0 at the time of this penetration test — perhaps due to regression or it never being fixed originally.
These issues were disclosed to Dell demonstrating that they affected the current version. At this time, the impact of the authentication bypass was also explained and disclosed, but Dell stated this was intended functionality of the application and would not fix the issue.
What is OpenManage Server Administrator (OMSA)
From the OMSA documentation:
“OpenManage Server Administrator (OMSA) is a software agent that provides a comprehensive, one-to-one systems management solution in two ways: Integrated web browser-based graphical user interface (GUI) Command line interface (CLI) through the operating system.”
In other words, OMSA provides some central monitoring and control of servers on which it is installed. OMSA also allows management of remote systems through a central web interface, Distributed Web Server (DWS), via the “managed systems login” functionality.
OMSA Authentication Bypass Working As Intended
The authentication bypass using the technique discussed by Harrison Neal here was also disclosed to Dell during the CVE-2020-5377 disclosure in version 9.4.0.0 and 9.4.0.2, but Dell determined it to be working as intended.
To give a brief overview of how the authentication bypass works, OMSA offers the ability to use a central server to log in to remote systems in order to manage them through a single web interface via the Distributed Web Server (DWS). This functionality is enabled by default.
Authentication bypass is possible by hosting a “rogue” remote node that replies to the authentication request from the OMSA server and validates the login causing the OMSA server to issue a web session for the user. The web session is intended to only render content from the remote node in the centralized web interface. However, it was found that in versions 9.4.0.0 and 9.4.0.2 of OMSA, this session allows privileged access to the underlying APIs.
This is the setting where Managed System Login can be enabled and disabled.
A simplified diagram of the OMSA authentication bypass steps.
In Step 4 of the image above, the server issues a JSESSIONID cookie and a VID which grants a privileged session to the OMSA web interface and can then be used to make subsequent privileged API requests directly to the OMSA server.
File Read Vulnerability Details
The OMSA web interface uses Apache Tomcat. Taking a look in the web.xml an interesting authenticated servlet is exposed at /DownloadServlet.
<servlet><servlet-name>DownloadServlet</servlet-name><servlet-class>com.dell.oma.servlet.secure.DownloadServlet</servlet-class></servlet>
After decompiling the OMSA.jar file and looking at this class there is an obvious file read vulnerability.
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);
}
Here you can see the “file” GET parameter is set to “str1” and is passed to FileInputStream, and read into the response of the application. The only check is that our “user rights” for our web session is “7”, which is satisfied by the session we obtained through the authentication bypass. This allows us to read any path on the file system we would like.
The vulnerable request looks like the following:
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 fix of CVE-2020-5377, a security filter which is intended to protect the DownloadServlet servlet from reading arbitrary files was implemented, but able to be trivially bypassed.
When calling DownloadServlet a filter is used to look for malicious paths being passed to the DownloadServlet and the request should be rejected.
The filter:
<filter-name>PathManipulationFilter</filter-name> <filter-class>security.web.PathManipulationFilter</filter-class>
A snippet of the relevant decompiled 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);
}
The code above shows a snippet of the filter code. Each request URL is passed to the isFileHandlerRequest method to test if the URL contains any of the strings listed in HashMap “a”. Since “a” only contains literal strings, this does not take into account any kind of encodings. This filter can be bypassed entirely by simply URL encoding part of the URL path causing the isFileHandlerRequest method to return false.
Now the URL looks like:
https://omsa.server/{VID}/DownloadServle%74?help=Certificate&app=oma&vid={VID}&file=C:\some\file
The t is URL encoded as %74, and the request succeeds.
CVE Proof Of Concept
We have created a proof of concept that will obtain a valid session cookie and use the session to read a file from the server.
The POC can be found in our CVE repo on GitHub: https://github.com/RhinoSecurityLabs/CVEs/tree/master/CVE-2020-5377_CVE-2021-21514
Demonstration of the Dell exploit and proof of concept.
Mitigating the Dell Vulnerability
Dell released a patch for the vulnerabilities that were disclosed: two file reads, and an arbitrary file write via directory traversal. However, they determined the authentication bypass using remote management login was intended functionality. This would mean that even after patching, it may still be possible to obtain a valid session cookie to the API using this authentication bypass. If you do not use the remote management login, you should disable it to eliminate this attack surface.
Disabling the managed system login can be done via the following steps:
- On the login screen, click “Manage Web Server”
- Login using the systems administrator credentials
- Click “Preferences”
- Switch “Managed System Login” to “Disabled”
Conclusion
Using the authentication bypass opens up quite a few possibilities as to what could be done maliciously using the API as demonstrated with a file read.
There may be other dangerous functionality that can be reached once a valid session cookie is obtained. For this reason, we strongly recommend you disable “Managed System Login” if you are not using your OMSA web interface to access remote systems. If you are not using OMSA at all, you should uninstall or disable the service entirely. If it is in use, of course, keep the version that is running up to date and patched.
Thanks for reading, check back frequently for more blog posts, research, and tool releases. In the meantime, follow us on Twitter for news and updates: @RhinoSecurity, @daveysec
Dell Vulnerability Disclosure Timeline
4/27/2020 – Disclosure of initial findings to Dell. authentication bypass, 2 file reads and arbitrary file write
4/30/2020 – Dell acknowledges initial disclosure.
5/18/2020 – Dell accepts all issues except authentication bypass stating “it is working as intended”.
5/22/2020 – Dell updates on expected fix to be released July 31st.
7/27/2020 – Dell publishes initial fix and advisory.
9/17/2020 – Rhino urges Dell to take a second look at the authentication bypass.
9/18/2020 – Dell indicates they will review the previously reported authentication bypass.
9/22/2020 – Dell requests we attempt the authentication bypass again with the most recent patch installed.
11/14/2020 – Rhino tests the most recent patched version 9.4.0.2 for the authentication bypass issue and reviews the previous patch for directory traversal.
11/16/2020 – Rhino reports a bypass for the directory traversal and informs Dell the authentication bypass is still present in the most recent patch.
11/17/2020 – Dell acknowledges newly reported issues.
12/3/2020 – Dell accepts the directory traversal bypass and again rejects the authentication bypass with the note:
“Our OMSA security team also reviewed the Authentication Bypass finding and concluded that by design OMSA allows any valid network user to connect any Managed Node(s) within the network. This issue is a duplicate of an earlier ticket PSRC-12558 that you reported in April.”
3/2/2021 – Advisory released by Dell. https://www.dell.com/support/kbdoc/en-us/000183670/dsa-2021-040-dell-emc-openmanage-server-administrator-omsa-security-update-for-multiple-vulnerabilities
