ThinManager Path Traversal Upload (CVE-2023-27855) Module #20138
Conversation
| begin | ||
| connect | ||
| rescue Rex::ConnectionTimeout => e | ||
| fail_with(Failure::Unreachable, "Connection to #{datastore['RHOSTS']}:#{datastore['RPORT']} failed: #{e.message}") |
There was a problem hiding this comment.
check methods should exclusively return checkcodes and not raise exceptions/fail_with
|
|
||
| register_options( | ||
| [ | ||
| OptString.new('LFILE', [false, 'The local file to transfer to the remote system.', '/tmp/payload.exe']), |
There was a problem hiding this comment.
| OptString.new('LFILE', [false, 'The local file to transfer to the remote system.', '/tmp/payload.exe']), | |
| OptPath.new('LFILE', [false, 'The local file to transfer to the remote system.', '/tmp/payload.exe']), |
| res = sock.get_once(4096, 5) | ||
| expected_header = "\x00\x04\x00\x01\x00\x00\x00\x08".b | ||
|
|
||
| if res && res.start_with?(expected_header) |
There was a problem hiding this comment.
| if res && res.start_with?(expected_header) | |
| if res&.start_with?(expected_header) |
| return Exploit::CheckCode::Safe | ||
| else | ||
| disconnect | ||
| returnExploit::CheckCode::Unknown('No handshake response received.') |
There was a problem hiding this comment.
| returnExploit::CheckCode::Unknown('No handshake response received.') | |
| return Exploit::CheckCode::Unknown('No handshake response received.') |
| include Msf::Exploit::Remote::Tcp | ||
| include Msf::Auxiliary::Report | ||
| prepend Msf::Exploit::Remote::AutoCheck | ||
| CheckCode = Exploit::CheckCode |
There was a problem hiding this comment.
Is this necessary or can we just use Exploit::CheckCode throughout?
There was a problem hiding this comment.
I can change it to Exploit::CheckCode instead. I think in one of my past modules it was recommended to use CheckCode = Exploit::CheckCode, that's why I had used it instead. Either way is fine for me.
There was a problem hiding this comment.
It looks like you're only using the Checkcode once without using Exploit::Checkcode.
It would make sense to me to have Exploit::Checkcode if code complexity made the likelihood of returning a non-Exploit::Checkcode object from the check method possible by accident, but I don't think we're looking at that level of complexity in the check method, yet.
| print_status('Received handshake response.') | ||
| vprint_status(Rex::Text.to_hex_dump(res)) | ||
| else | ||
| print_error('No handshake response received.') |
There was a problem hiding this comment.
Should we be exiting early here? using fail_with like you're doing here https://github.com/rapid7/metasploit-framework/pull/20138/files#diff-f371660e0b23cb2a2840800144bcbe7c7c969a211fdb039a9047ffd81aa27f8eR95
There was a problem hiding this comment.
We've noticed that this module has a lot of overlap with your other modules particularly with the handshake/sending/receiving of data, do you think it's worth putting some time into consolidating that into a library for use by all of these modules/any future modules targeting this software?
|
Is this supposed to be |
|
|
For future me, I'm using Win10_2004_2551 for testing. |
I had it initially in |
| vprint_status('Received handshake response.') | ||
| vprint_status(Rex::Text.to_hex_dump(res)) | ||
| disconnect | ||
| return CheckCode::Detected |
There was a problem hiding this comment.
I think this is the only place you're using CheckCode without using Exploit::CheckCode
This module exploits a path traversal vulnerability in ThinManager <= v13.0.1 (CVE-2023-27855) to upload an arbitrary file to the target system.
The affected service listens by default on TCP port 2031 and runs in the context of NT AUTHORITY\SYSTEM.
Verification Steps
msfconsoleuse auxiliary/gather/thinmanager_traversal_uploadset LFILE <local file location>set RFILE <remote file location>runExample output:
Successfully tested on