-
Notifications
You must be signed in to change notification settings - Fork 13.8k
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 RCE Exploit For CVE-2020-0796 (SMBGhost) #15024
Conversation
@@ -106,7 +106,7 @@ | |||
</SDLCheck> |
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.
I updated this file so the build paths are still correct after being moved into the LPE subdirectory. The original exploit binary is unmodified, this just means you can still open Visual Studio, hit build and things will work as intended.
I'm unable to get this to work on wither a 1903 or 1909 (x64) Windows VM running on ESXi. I've run it a couple times, and it seems to always fail in this error.
I added the 'hal' part locally to make sure I was seeing the error message I thought I was. |
Can you load a local kernel debugger and share the memory around |
documentation/modules/exploit/windows/smb/cve_2020_0796_smbghost.md
Outdated
Show resolved
Hide resolved
For the record, this is delayed as I work through an issue whereby a successfully exploited system may die with a BSOD from a 109 bugcheck triggered by Patch Guard approximately 0-80 minutes after the exploit runs. |
Alright, I'm stuck on bypassing Kernel Patch Protection. I've restored all of the contents in KUSER_SHARED_DATA and the PTE settings by re-enabling NX. Windows however is still crashing. I'm not entirely sure why Windows is still crashing. My best guess based on this Tetrane PatchGuard Analysis is that the APC which is queued as part of the kernel mode bootstrap is getting caught. This is mentioned in section III. C. on page 37. Of course I'm not sure this is what it is or if it's the only thing remaining that's getting caught and I won't be sure until I'm able to bypass it. Next steps to attempt to bypass this protection seem significantly more complicated than my attempts so far. I think the best bet would be to use cat1357/ByePg. This project hooks the exception handling to prevent the BSOD from occurring despite PatchGuard triggering it. The problem is this is a driver written in C++ (presumably to be used by cheat/anit-cheat engines). To use this in the context of this exploit it'd need to be converted into position-independent shellcode or combined with a reflective loader (like Professor-plum/Reflective-Driver-Loader. That's a lot of work, which bothers me less than the degree to which I'm uncertain it would even yield the desired results. If it did work though, it ould be reused pending any Windows version-specific caveats which I am currently unaware of but likely exist. I'm leaning towards bumping the reliability down to low or manual and documenting that the exploit has a decent chance of BSODing the system even after successfully opening a session and that the recommended course of action is to use the time to setup persistence somehow and force a reboot. Those steps I think should be left up to the user so Metasploit isn't overfitting a solution that would write a payload to disk when it's possible that it's only necessary to dump hashes / passwords and log back in later. |
Windows 10x64 1909
|
Windows 10x64 1903
|
Release NotesNew module |
This adds an exploit for CVE-2020-0796 which can be used to gain unauthenticated remote code execution against unpatched Windows 10 v1903 and v1909 systems. Metasploit currently has an LPE version of this exploit but no RCE. The exploit is heavily based on the chompie1337/SMBGhost_RCE_PoC PoC. I updated the HAL heap scanning (because it wasn't working on my system) and the kernel mode shellcode. The kernel shellcode was updated to be compatible with Metasm, which allows Metasploit to patch in some values at runtime. It was also updated to move the storage space to the end of the usermode payload which reduces the size by 154 bytes.
I've tested this successfully against Windows 10 v1903 and v1909 VMs. It's not 100% reliable, and when it fails it does occasionally cause a BSOD. The read primitive to dump physical memory can be slow and this module will reattempt it quite a few times to avoid losing progress as it extracts a bunch of information from the target system.
The check method, like all the scanners I found, simply verifies that SMB 3.1.1 is enabled with the LZNT1 compression algorithm. This results in a reliable detection of the service, but without running the exploit and triggering it, I was unable to determine with any higher degree of confidence whether or not the remote system is unpatched. When sending a corrupt from to both a vulnerable 1909 and fully patched/immune 20H2 system, they both simply terminate the connection. Triggering the vulnerability results in kernel-mode memory corruption, so probably not a good idea to attempt from a check method.
This bumps the
ruby_smb
gem to version 2.0.8 to pull in these required changes which fixes an issue with theCompressionTransformHeader
definition and adds the LZNT1 compression algorithm.Verification
List the steps needed to make sure this thing works
msfconsole
use exploit/windows/smb/cve_2020_0796_smbghost
RHOST
andPAYLOAD
optionsVERBOSE
to see that things are happening)Demo