Now that a patch has been available for Dell OMSA to fix CVE-2016-4004 et
al for a few days, I feel more comfortable discussing a severe variant of
the vulnerability that works against Linux hosts (new!) and does not
require credentials that work on the victim host (new!).

Admins running Dell OMSA on their servers should update the application to
v8.5.

The following can be treated as an addendum to [1] and a response to [2],
and has been found to work on Dell OMSA 7.x and 8.x before 8.5.  Testing
occurred on CentOS 6, CentOS 7 and RHEL 7.  In all cases, the application
was installed using the consolidated Linux download and installing the RHEL
packages (which, for CentOS, required minor modifications to the installer
such that it identified CentOS as RHEL).



Introduction ===========================



Two major shortcomings of [1] were as follows:

1: Certain security checks on the file parameter required traversing into a
potentially non-existent directory and back out of it, something which is
allowed on Windows but not on Linux.

2: The exploit required logging in to the application as a privileged user.

Both of these shortcomings can be easily resolved.



Support for Linux ======================



The first shortcoming can be resolved as follows:

tl;dr: upload a file, get a valid link, and then put the directory
traversal in the app parameter, not the file parameter

There is another parameter you can optionally use, app, which does not
appear to have security checks done on it, and thus lets you do a clean
directory traversal that would work on Linux.

At this point, the only concern is the value of the parameter path, which
both needs to exist and needs to be one of the allowed values.  There is
e-mail form functionality with attachment capabilities in this application,
which serves our purposes well.  Either click the aE-mail [Page]a button
anywhere throughout the application, or choose to upload a file as an
attachment to an e-mail, and a link will appear in the e-mail form
representing a new attachment.  You may use the value of the path attribute
in the link, knowing that the path now exists.

If the application doesnat have SMTP settings configured, the e-mail form
may not display, but that does not stop you from uploading a file if you
issue an appropriate POST request.

If you scripted up logging into your own server, uploading an attachment,
and then abusing the vulnerability, the latter might look like:

https://IP:1311/VID/ViewFile?path=/oma/upload/0&app=../../../../../../../../../../../../../../..&file=etc/shadow&vid=VID



Avoiding Authentication ================



The second shortcoming can be resolved as follows:

tl;dr: click aManage Remote Nodea at the bottom of the login screen, then
provide the IP of a server you control

If you read between the lines in [1], it merely says awhen authenticated as
an admina; it never says an admin on the victim host.  On a default
installation of Dell OMSA with all components installed on a supported Dell
server, at the bottom of the login screen youall notice a link that reads
aManage Remote Nodea, which will take you to the aManaged System Logina
page.  Here, you can specify both a host and the credentials for that
host.  If only the web server interface component is installed, or the
server is not a Dell server, the application may default to showing this
aManaged System Logina page.

When you choose to log in to a specific host, the application will attempt
to connect to a WS-Management server on the specified host, authenticate if
necessary, and you will be logged into the application if the WS-Management
server supports certain Dell-specific extensions.

For those of us either on a budget or that wouldnat like bringing Dell
servers along on pentests, it isnat terribly complicated to create a fake
server that passes for a amanaged systema.  Two example minimalistic
implementations that are just barely enough to get you through the front
door and to the vulnerability are available at [3] and [4].  These example
implementations donat require authentication, so any username and password
will work.  Youall probably need to make sure you check the aIgnore
certificate warningsa option, depending on your setup.

If you scripted up the Linux exploit above, at this point youad just modify
the login part to point to your system, and make sure a fake server is
running.

For the moment, Iall leave scripting all of this up as an exercise for the
reader.



References =============================



[1]: https://www.exploit-db.com/exploits/39486/

[2]:
http://topics-cdn.dell.com/pdf/dell-openmanage-server-administrator-8.4_Release%20Notes10_en-us.pdf

[3]: https://github.com/hantwister/FakeDellOM

[4]: https://www.exploit-db.com/exploits/39909/ (lines 65-107)