Add ManageEngine DataSecurity Plus directory traversal exploit module and docs (CVE-2020-11531)

[ErikWynter]

About

This change adds a new exploit module (docs) that exploits CVE-2020-11531 and CVE-2020-11532 against ManageEngine DataSecurity Plus. The change also adds several JSON files that are required for preventing the exploit from breaking DataSecurity Plus. This PR depends on https://github.com/rapid7/metasploit-framework/pull/16725 because it leverages a mixin at lib/msf/core/auxiliary/manageengine_xnode that is added there. The module currently leverages code from the web_delivery module in order to overcome severe payload limitations (see Notes below for more info on this).

Vulnerable systems

The module exploits default credentials (CVE-2020-11532) and a path traversal vulnerability (CVE-2020-11531) in the DataEngine Xnode server in ManageEngine DataSecurity Plus versions prior to 6.0.1 (6011). These issues are chained in order to achieve remote code execution with local administrator privileges.

Notes

• A full writeup of how Xnode works, how CVE-2020–11531, and why this module leverages code from the web_delivery module is available here
• A demo video is available here.
• The module comes with documentation that explains how it works and how to use it
• As described in the documentation and writeup, this exploit will wipe a bunch of Xnode configuration files that Xnode requires to function. In order to prevent breaking Xnode, which would actualy make it impossible to restart DataSecurity Plus, this changes add the default Xnode configuration files (all JSON files), and uses those to repopulate the Xnode configuration when exploitation is successful. This makes it possible to use the exploit multiple times against the same system without breaking Xnode.
• As mentioned above, the module in its current form includes code that was taken from the web_delivery module, because this was the only approach that allowed me to get a shell in msf in a clean manner (see the writeup for more info). If anyone can find a better approach, I'd be happy to incorporate that instead. However, if we do proceed with the web_delivery strategy, it would probably make sense to move some of the web_delivery code to a mixin so that both the original web_delivery module and my module can leverage it. I've written mixins before so I'd be happy to whip that up.
• I ran Rubocop and was able to fix all issues except the one below, because that one resides in the web_delivery code that was copied over (and it shows up when I run Rubocop against that module too):

modules/exploits/windows/http/manageengine_datasecurity_plus_traversal_rce.rb:128:5: C: Naming/MemoizedInstanceVariableName: Memoized variable @amsi_uri does not match method name amsi_bypass_uri. Use @amsi_bypass_uri instead.
    @amsi_uri ||= random_uri
    ^^^^^^^^^

If changes are required to fix this issue, please let me know.

• Information about where to get the software for testing is available in the docs.
• Please let me know if anything is missing or requires elaboration. Feel free to ping me on the Metasploit slack (I'm wynter). :)

[ErikWynter]

Just wanted to highlight that the failure of the checks is expected:

• lint failed because of the Rubocop issue I mentioned in the PR notes
• The second one failed because the module relies on the mixin that is added in https://github.com/rapid7/metasploit-framework/pull/16725

[ErikWynter]

Little update: this PR will require updates based on changes made to the lib in https://github.com/rapid7/metasploit-framework/pull/16725 during code review. I will push those changes once that PR has been landed or is about to be.

[gwillcox-r7]

Adding Delayed tag to this since this depends on us landing another PR before this can be landed. Once that PR is landed, we can remove the delayed tag.

[ErikWynter]

now that #16725 got landed, I will start making some changes to this one to make it compatible with the updated library. might be able to simplify some other stuff too. this will probably have to wait until next week though

[smcintyre-r7]

The 28 configuration files are pretty concerning.

1. Do we know if these are licensed? I'm not sure we can even redistribute these.
2. How confident are you that if the files are restored, the system will remain functional? Is this not just going to undo the target's site configuration?

If the exploit is going to revert the target's configuration to it's default state, that's destructive.

Looks like we're still waiting on these changes to be rebased to incorporate the upstream library modifications.

However, if we do proceed with the web_delivery strategy, it would probably make sense to move some of the web_delivery code to a mixin so that both the original web_delivery module and my module can leverage it. I've written mixins before so I'd be happy to whip that up.

I'd really prefer to see those implemented using the new payload adapters. That would make them compatible out of the box with ARCH_CMD payloads and would serve the same purpose as the web-fetching command stagers. Using a payload adapter would make it easier for module authors, and allow the user to make more specific configuration changes through the datastore.

[github-actions[bot]]

Thanks for your contribution to Metasploit Framework! We've looked at this pull request, and we agree that it seems like a good addition to Metasploit, but it looks like it is not quite ready to land. We've labeled it attic and closed it for now.

What does this generally mean? It could be one or more of several things:

• It doesn't look like there has been any activity on this pull request in a while
• We may not have the proper access or equipment to test this pull request, or the contributor doesn't have time to work on it right now.
• Sometimes the implementation isn't quite right and a different approach is necessary.

We would love to land this pull request when it's ready. If you have a chance to address all comments, we would be happy to reopen and discuss how to merge this!

[smcintyre-r7]

I've attic'ed this one. The license on the configuration files is really concerning and the degree to which this is destructive in the sense that 28 data files have to be restored is equally concerning. If I'm missing something or there's a way around, let me know and we can reopen it.

[ErikWynter]

@smcintyre-r7 hey sorry for the radio silence, I had one hell of a week. I'll try and dig up my notes on this one next week and address the issues mentioned above. I think the exploit itself could potentially be simplified but I'll have to see about the license situation and about possible solutions.

[ErikWynter]

@smcintyre-r7 alright, finally had some time to look into this and I actually agree with you that it would be safer not to include this one for several reasons:

• I'm not sure about the licensing of those config files. The files themselves don't contain a note about licensing, which probably means they fall under the general ManageEngine license for this product and cannot be redistributed.
• More importantly, I can't see a way to run this exploit while avoiding the destructive impact, even if we could ship the license files. The exploit can only work by wiping the config files from the <install_dir>\apps\dataengine-xnode\conf\datarepository\schema\ directory, and Xnode needs those files in order to function.
  • If the files are not restored, it will break Xnode and even make it impossible to reboot DataSecurity Plus. In other words, the module would essentially be an Exploit/DoS combo.
  • If they are replaced by the default config files (which may not always work even if you get a shell), Xnode will still work, but any differences between the original config files and the default files could result in data loss or at least prevent DataSecurity Plus from retrieving that data via Xnode. Given this, the risk of this module resulting in some form of DoS is very significant and cannot be avoided.

I'm sorry I did not sufficiently consider the destructive impact before opening the PR.