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 exploit for NUUO NVRmini2 zero day unauth RCE as root #16044
base: master
Are you sure you want to change the base?
Conversation
|
TODO:
I'll do this in the next couple of days! |
|
What does this mean? |
It typically refers to a variable that's not used anywhere in the module. |
Co-authored-by: adfoster-r7 <60357436+adfoster-r7@users.noreply.github.com>
|
CVE ID requested, coming soon (they're usually pretty quick). |
|
Thanks for your pull request! Before this can be merged, we need the following documentation for your module: |
|
Thanks for your pull request! Before this pull request can be merged, it must pass the checks of our automated linting tools. We use Rubocop and msftidy to ensure the quality of our code. This can be ran from the root directory of Metasploit: You can automate most of these changes with the Please update your branch after these have been made, and reach out if you have any problems. |
|
If this were converted over to deliver an ARCH_PHP payload we may be able to avoid the need for the HTTP server interactions You can check out an example of this here: https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/unix/webapp/thinkphp_rce.rb#L223 |
|
@dwelch-r7 unfortunately that's not really possible... the target uses a custom encryption scheme which was too lazy to reverse, as that would take substantially more time than I have available. |
|
Docs added, now we just need that CVE and it's good to go! |
|
all done, good to go |
|
ok had a typo, now ready to go 4 real (final final x2 version) |
Sorry to be the bearer of bad news @pedrib but after speaking internally with our team unfortunately the decision at the moment is that we can't move this forwards unless we have a way to generate the binary blob ourselves to attest to its integrity. This is the same as our general policy of not allowing arbitrary binaries that we can't compile ourselves into Metasploit Framework. Once we have a way to generate this binary blob we will be happy to move this forwards. If you have more questions on this @smcintyre-r7 will likely be able to assist you, I'm just relaying on the info he gave me when we had a chat about this. |
|
@gwillcox-r7 @smcintyre-r7 you guys are breaking my balls... but it's understandable. I'll need to get some free time to reverse the encryption. Don't close this PR please! |
|
Hi @pedrib, I'm just checking-in to see if you could make progress on this or if you need any help from us. Thanks! |
|
hi @cdelafuente-r7 thanks for asking! Unfortunately haven't had the time to reverse engineer the encryption yet, but it's on my TODO list! |
|
I wonder - if we could just document the steps for manually encrypt files ourselves - if that would be enough to unblock this PR? i.e. We don't need to verify the decryption is valid - just that we get the expected encrypted file that we're after for RCE? Just as a sanity question - is the encryption method the same for all devices? i.e. I assume the same encrypted payload works across different devices as well? |
|
@adfoster-r7 you can check the exact steps in the advisory: Regarding your question about the device, it most definitely will work on any device, since there is no device dependant encryption, the encryption is done in the firmware (which is not customised per device). I did confirm that it works across different firmware versions, but would be good to get someone else to confirm too if you have access to the device? |
|
Hi all, I'm on the verge of just atticing this PR. We will ultimately need to make the binary blob ourselves. We could go in and try A second concern is that the info at https://github.com/pedrib/PoC/blob/master/advisories/NUUO/nuuo_nvrmini_round2.mkd seems to be behind a GPLv3 license which is incompatible with Metasploit and is not something we can accept. This comes from legal which mentioned that GPLv3 is not something we can legally accept for Metasploit right now. GPLv2 is acceptable and LGPL is acceptable however, as are other common licenses such as MIT, so if you wanted to relicense the research to one of these, this would be acceptable. I was trying to download the firmware but its behind a login page and it seems their backend can't authenticate to send the emails out. Either that or it really hates temp emails |
|
@gwillcox-r7 please don't ax it! I just need a bit of time, but I will come back to it... You don't need the device, the firmware can be easily emulated, I can put the steps here. I can also provide you with the firmware. Regarding the GPLv3, I don't think that's a problem... I've submitted over 50 modules to msf before, and they are all based off GPLv3 advisories... first of all the advisory is not an essential part of the module; secondly I am the creator of this module and of the advisory, so I don't see how that could be a problem. |
|
@pedrib Thanks, after speaking with the team I think so long as the binary blobs and module itself are licensed under MSF_LICENSE we should be fine there; my concern was mainly that the binary blobs were GPLv3 licensed that you had created and included in the module itself. I'll await your updates so long |
|
@gwillcox-r7 thanks, I will come back to this! |
This module exploits two vulnerabilities in NUUO's NVRmini2 NVR device.
It allows an unauthenticated attacker to achieve remote code execution as root, and works on all firmwares ever released.
More information in my advisory