Message-ID: <CA+i6_hVeR4N+Ftp=jZsjQh=whz9YrqRFT-zjK_3eSzBm2pNJAg@mail.gmail.com>
Date: Mon, 03 Apr 2017 22:58:11 +0000
From: Harrison Neal <hneal@...tdidibreak.com>
To: "fulldisclosure@...lists.org" <fulldisclosure@...lists.org>
Subject: [FD] Dell OpenManage Server Administrator v8.4: CVE-2016-4004
	Addendum

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 “E-mail [Page]” 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 doesn’t 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 “Manage Remote Node” 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 “when authenticated as
an admin”; 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 you’ll notice a link that reads
“Manage Remote Node”, which will take you to the “Managed System Login”
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
“Managed System Login” 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 wouldn’t like bringing Dell
servers along on pentests, it isn’t terribly complicated to create a fake
server that passes for a “managed system”.  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 don’t require authentication, so any username and password
will work.  You’ll probably need to make sure you check the “Ignore
certificate warnings” option, depending on your setup.

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

For the moment, I’ll 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)

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists