-
Notifications
You must be signed in to change notification settings - Fork 13.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
unquoted_service_path does not write the payload successfully #19029
Comments
I had a quick look at this.
The module reports the payload was written to disk but does not check whether the file write was successful. metasploit-framework/modules/exploits/windows/local/unquoted_service_path.rb Lines 172 to 174 in 4ecd106
You could check with something like this: diff --git a/modules/exploits/windows/local/unquoted_service_path.rb b/modules/exploits/windows/local/unquoted_service_path.rb
index 634d5b7f87..13e098469a 100644
--- a/modules/exploits/windows/local/unquoted_service_path.rb
+++ b/modules/exploits/windows/local/unquoted_service_path.rb
@@ -170,7 +170,12 @@ class MetasploitModule < Msf::Exploit::Local
print_status(" Placing #{exe_path} for #{svc_name}")
exe = @svc_exes[svc_name] ||= generate_payload_exe_service({ servicename: svc_name })
print_status(" Attempting to write #{exe.length} bytes to #{exe_path}...")
- write_file(exe_path, exe)
+
+ unless write_file(exe_path, exe)
+ print_error("#{exe_path} could not be written")
+ next
+ end
+
print_good ' Successfully wrote payload'
register_file_for_cleanup(exe_path) It is possible that the payload was written but is cleaned up automatically upon completion. You can verify by removing the cleanup (then check if diff --git a/modules/exploits/windows/local/unquoted_service_path.rb b/modules/exploits/windows/local/unquoted_service_path.rb
index 634d5b7f87..0f10ccd30e 100644
--- a/modules/exploits/windows/local/unquoted_service_path.rb
+++ b/modules/exploits/windows/local/unquoted_service_path.rb
@@ -172,7 +172,7 @@ class MetasploitModule < Msf::Exploit::Local
print_status(" Attempting to write #{exe.length} bytes to #{exe_path}...")
write_file(exe_path, exe)
print_good ' Successfully wrote payload'
- register_file_for_cleanup(exe_path)
+ #register_file_for_cleanup(exe_path)
#
# Run the service, let the Windows API do the rest If the file is cleaned up too early, you could work around this using by setting For what it's worth, I tested the module successfully on a vulnerable system:
|
Hi! This issue has been left open with no activity for a while now. We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 30 days since the last update here. As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. |
Hi again! It’s been 60 days since anything happened on this issue, so we are going to close it. As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. |
Steps to reproduce
In a meterpreter session with a target that has an unquoted service path vulnerability, running the module
unquoted_service_path
returns that it was successful. But upon further investigation, the payload wasn't written even if the user has Full Control permissions on theC:\
directory.The user doesn't have permissions to restart the service, but the output says that it successfully wrote the payload to
C:\Program.exe
and that the payload is left on disk. But when I list the contents of that directory,Program.exe
doesn't exist:Were you following a specific guide/tutorial or reading documentation?
https://github.com/rapid7/metasploit-framework/blob/master/documentation/modules/exploit/windows/local/unquoted_service_path.md
Expected behavior
The payload
Program.exe
would be written toC:\
Current behavior
Nothing was written to
C:\
Metasploit version
Additional Information
I was able to exploit the unquoted service path manually.
This lab is from an INE course, the IP address seems to not fall in the private IP range so I just redacted it for safety.
The text was updated successfully, but these errors were encountered: