Bugfix Msf::Exploit::FileDropper.file_dropper_exist? for Windows sessions #18844
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When using the
FileDropper
mixin for a shell session on the windows platform, it appears the functionfile_dropper_exist?
may have been broken for ~9 years, preventing files and directories from being deleted if they exist. The functionshell_command_token
was being called, but it should besession.shell_command_token
.An exception was being thrown when the function
shell_command_token
could not be found, and swallowed (silently unless you have debug logging enabled) inMsf::Payload::on_session
:Additionally, the logic in the
file_dropper_exist?
function for windows shell sessions is wrong. The function should test if a path is either a file or a directory, the logic current only tests is a path is a file and return false if it is a directory. This does not match how the test is done on either meterpreter sessions or non windows shell sessions. (I think the code was copied from the File post modules back when FileDropper only supported cleaning up files, but now FileDropper supports directories, sofile_dropper_exist?
must test for either. the Windows shell command IF EXIST will test for both implicitly)So with the 2 fixes mentioned in this pull request, the following works as expected in my testing: