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)