-
Notifications
You must be signed in to change notification settings - Fork 14.3k
Add exploit for CVE-2021-1732 #14907
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
Conversation
0d7b662
to
0bff88c
Compare
Disregard the handler bind and module failures- I already had a listener running.
|
Release NotesNew module |
Is this 100% reliable for you guys? It seems about 30% reliable for me on |
I tried it about 6-7 times, and it only failed once? In that one case, I was able to just run it again, and it worked. |
Since it's really quick and doesn't seem to bsod (or have any side effects), I was tempted to wrap the exploit in a for loop (so it tries multiple times until succeeding), but manually re-running probably makes more sense. Nice work btw! |
Yeah it wasn't exactly 100% reliable for me either but my thought was that it was "good enough" for |
This adds an exploit for CVE-2021-1732 which is a vulnerability in win32k. By calling
NtUserConsoleControl
in a callback function and passing the window that is currently being created, a field can be switched to an offset despite containing an attacker-controlled value. This is used to build read and write primitives to access kernel memory. Once build, the primitives are used to steal a SYSTEM token from PID 4.In my testing the exploit is pretty reliable. When it does work, it fails gracefully and does not cause a BSOD though it is certainly theoretically possible that it could, I just haven't observed that behavior. I've tested this on all 6 affected versions of Windows 10 from 1803 through 20H2. I tested 1709 as well but the exploit does not appear to work for that one despite it supposedly being vulnerable. Version 1709 is no longer in service and is thus not listed by MSRC as an affected system.
From a user's perspective the exploitation process is pretty straight forward, there are no special options. The entire thing takes place in memory. Like many RDLL, exploits a process is created to host the DLL which is then elevated before the payload is executed. This logic is actually used in so many places that I moved it into a Mixin since it's copied and pasted among quite a few exploits.
Verification
List the steps needed to make sure this thing works
msfconsole