-
Notifications
You must be signed in to change notification settings - Fork 14.1k
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
Add Module for CVE-2023-36874, Windows Error Reporting #18314
Conversation
.cpp.cpp file? |
I'm old and confused, and when VS asks for a filename, I still assume it wants an extension. 😆 I'll fix it. |
This is now pretty close. I still need to:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @bwatters-r7 for this module! I left a few comments for you to review when you get a chance. I'll start testing now.
...ce/exploits/CVE-2023-36874/CVE-2023-36874/CVE-2023-36874/~AutoRecover.CVE-2023-36874.vcxproj
Outdated
Show resolved
Hide resolved
vprint_status("shadow_path = #{shadow_path}") | ||
exploit_bin = exploit_data('CVE-2023-36874', 'CVE-2023-36874.exe') | ||
write_file(exploit_path, exploit_bin) | ||
sleep 3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We might want to use EXECUTE_DELAY
datastore option instead of an hardcoded value. I'm wondering if it is useful to have two sleep
call, one before calling upload_execute_exploit
in exploit
and here. Maybe we could just have one here?
external/source/exploits/CVE-2023-36874/CVE-2023-36874/CVE-2023-36874/cve_2023_36874.cpp
Outdated
Show resolved
Hide resolved
external/source/exploits/CVE-2023-36874/CVE-2023-36874/CVE-2023-36874/cve_2023_36874.cpp
Show resolved
Hide resolved
external/source/exploits/CVE-2023-36874/CVE-2023-36874/CVE-2023-36874/cve_2023_36874.cpp
Show resolved
Hide resolved
Thanks for the review! I'm working on getting it to take arbitrary report values, and it was working earlier, and then it quit working. I'm going to need another day to sort out what's going on. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @bwatters-r7 for updating this. I just left a few last comments before it lands. I tested against Windows 10 22H2 build 19045.2006 and it works great!
That said, I noticed two issues when the module tries to cleanup the directories registered by mkdir
.
- The path passed as argument is a reference to the string variable
wer_archive_dir
and it is stored in the@dropped_dirs
instance variable byregister_dirs_for_cleanup
. As a result,@dropped_dirs
will contain multiple references tower_archive_dir
with the same path:
From: /home/msfuser/metasploit-framework/lib/msf/core/exploit/file_dropper.rb:91 Msf::Exploit::FileDropper#on_new_session:
86: file_dropper_deleted?(session, file, exists_before)
87: end
88: end
89:
90: require 'pry';binding.pry
=> 91: @dropped_dirs.delete_if do |dir|
92: if file_dropper_check_cwd?(session, dir)
93: print_warning("Attempting to delete working directory #{dir}")
94: end
95:
96: exists_before = file_dropper_exist?(session, dir)
[1] pry(#<Msf::Modules::Exploit__Windows__Local__Win_error_cve_2023_36874::MetasploitModule>)> @dropped_dirs
=> ["C:\\ProgramData\\Microsoft\\Windows\\WER\\ReportArchive\\IDGuqJrRzs",
"C:\\wFlEfPpE\\ProgramData\\Microsoft\\Windows\\WER\\ReportArchive\\",
"C:\\wFlEfPpE\\ProgramData\\Microsoft\\Windows\\WER\\ReportArchive\\",
"C:\\wFlEfPpE\\ProgramData\\Microsoft\\Windows\\WER\\ReportArchive\\",
"C:\\wFlEfPpE\\ProgramData\\Microsoft\\Windows\\WER\\ReportArchive\\",
"C:\\wFlEfPpE\\ProgramData\\Microsoft\\Windows\\WER\\ReportArchive\\",
"C:\\wFlEfPpE\\ProgramData\\Microsoft\\Windows\\WER\\ReportArchive\\",
"C:\\wFlEfPpE\\ProgramData\\Microsoft\\Windows\\WER\\ReportArchive\\IDGuqJrRzs",
"C:\\wFlEfPpE\\system32"]
Only C:\wFlEfPpE\ProgramData\Microsoft\Windows\WER\ReportArchive
will be properly cleaned up. I don't think it is an issue with your module, but rather a change that needs to be done in register_dirs_for_cleanup
. Probably something like this:
def register_dirs_for_cleanup(*dirs)
@dropped_dirs += dirs.map(&:clone)
end
I'll put a PR up for this.
- The other issue is this error after the session pops up:
[-] Failed to delete C:\wFlEfPpE\system32: stdapi_fs_delete_dir: Operation failed: The directory is not empty.
This is probably due to the fact that C:\wFlEfPpE\system32\wermgr
is still running on the target. I'm not sure how to fix this. Maybe printing a warning that instructs the user to migrate to another process and execute rmdir C:\\wFlEfPpE
manually?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please, could you address the issues reported by msftidy_docs.rb
?
ruby tools/dev/msftidy_docs.rb documentation/modules/exploit/windows/local/win_error_cve_2023_36874.md
@cdelafuente-r7 Thanks for the review- to try and clean things up more, I:
|
Thank you @bwatters-r7! I just noticed the Options section does not follow the documentation template, but I will ninja commit this simple fix myself when it lands. I thought
|
Release NotesThis adds an exploit module that leverages a directory traversal vulnerability in Windows 10. This vulnerability is identified as CVE-2023-36874 and enables an attacker to elevate privileges to those of the |
This is a draft placeholder for the LPE CVE-2023-36874 that I'm working on.This module adds an exploit targeting CVE-2023-36874, a directory traversal vulnerability in Windows 10. This module works with Windows 10x64 22H2.
Closes #18303