search

rapid7 / metasploit-framework

Metasploit Framework
https://www.metasploit.com/
Other
34.06k stars 13.95k forks source link

db_nmap scan requires root privileges #12035

Closed Script-Nomad closed 3 years ago

Script-Nomad commented 5 years ago

Goals for this Issue

This issue is meant to point out a conflict between the Metasploit security model and the use of Nmap and other external tools which are integrated with it. Since the intent of the new MSF security model is to avoid running MSF as root, it makes sense for MSF to ask for sudo permissions when calling these tools (nmap being the prime example).

The hopeful solution should do the following:

Things this issue is not trying to achieve

This issue is not intended to seek help or workarounds for the problem of running nmap as root within Metapsloit, many of which exist and have been kindly suggested.

For those who are seeking workarounds so that you can run nmap within metasploit or import the results into msfconsole, this is the best way to do it...

Run nmap outside of metasploit with the -oX (xml output) or -oA (all nmap output files) flag and import the nmap .xml output into metasploit.

# Outside metasploit in a terminal ...
sudo nmap {*args} -oX /path/to/nmap-output.xml <target-ip>

# From msfconsole ...
msf> db_import /path/to/nmap-output.xml

For more workaround suggestions, see the recommended solutions by @githubismyresume and @bcoles below

With that out of the way, onto the rest of the issue. 😎

Steps to reproduce

msf5 > db_nmap -sS -sV -n -v --top-ports 100 8.8.8.8

Running db_nmap from an unprivileged user (as intended) results in the command failing because metasploit fails to either

  1. Request sudo privileges when executing nmap or
  2. Alter Nmap capability permissions so that it can open raw sockets as underprivileged users

Since the intent is for Metasploit & msfconsole to run without root permissions, option 1 should be the default behavior, as it is the safest option and the user running msfconsole should have sudo permissions anyway. Opening REX sockets in msfconsole as an underprivileged user does not appear to be plagued by this issue, but I am unsure how it is achieving this.

Expected behavior

Nmap runs without complaint

Current behavior

msf5 > db_nmap -sS -sV -n -v --top-ports 100 Scope/external-ips.txt   
[*] Nmap: 'You requested a scan type which requires root privileges.' 
[*] Nmap: 'QUITTING!'

System stuff

Metasploit version

Framework: 5.0.35-dev Console: 5.0.35-dev

I installed Metasploit with:

OS

Tested on ... Linux 4.9.0 Debian Stretch Linux 5.1.11 Fedora 30

Edit (12/7/2020): This issue has received a LOT of suggested workarounds, so I wanted to make my intent clear to the reader that this issue is not trying to seek workarounds, as several already exist and are well-documented. Please note the added "Goals for this Issue" and "Things this issue is not trying to achieve" headings at the top.

jeffmcjunkin commented 5 years ago

db_nmap doesn't intrinsically require root permissions, but the scan type (-sS) you selected does: https://nmap.org/book/synscan.html

Changing -sS to -sT should suffice for your use case. The actual error message you received was from nmap, not from msfconsole.

Script-Nomad commented 5 years ago

I'm aware that certain scan flags require root and others do not, but that's just a workaround for my example, not a complete solution. Note that this still leaves the user without the ability to perform simple ping -sn scans, aggressive -A scans, fingerprinting, or nse scripts as well. Those are things you need when running a pentest, so a workaround won't suffice. By that same token, I could just run nmap locally as root and import the scan results, which I do. It's not really so much of a problem I'm having that needs fixing, it's more that I see a shortcoming in the functionality of metasploit that I think could be improved.

My point is that Metasploit should be capable of elevating its permissions to perform any scan regardless if the user is in the sudoer's group. Metasploit does this when opening REX sockets, so it makes sense to enable db_nmap to do the same, though I expect the solution will be very different. In my mind, it would be better to enable the end-user full utility of all their various scans so that they have all the functionality right there within metasploit. Wouldn't you agree?

pastaoficial commented 4 years ago

Is there any new about it? I have had the same problem.

I need to perform scans that requires privileges

h00die commented 4 years ago

looking through the nmap documentation, while it mentions most things need privileged access, there doesn't seem to be a definitive list. Is there such a thing? This would make coding in when to ask much easier.

Script-Nomad commented 4 years ago

@hoodie, thanks for taking a look at this.

Per the documentation, it states that most scans require root access due to the requirement for crafting and sending raw packets which is a UNIX root privilege only.

Most of the scan types are only available to privileged users. This is because they send and receive raw packets, which requires root access on Unix systems. Using an administrator account on Windows is recommended, though Nmap sometimes works for unprivileged users on that platform when Npcap has already been loaded into the OS. [source: https://nmap.org/book/man-port-scanning-techniques.html ]

Having tested the scan types, the only scans that do not require root privileges are those which perform simple ICMP, TCP, and ARP pings. All other scan types either a) open a raw socket (root privileges required) b) perform some form of packet fragmentation (root privileges required) c) manually craft packet flags in a way that is not RFC standard (ex: Xmas scans which turn on all tcp packet flags)

Basically, any default or port-scan activity that is not -sn (ICMP echo ping + no port scan) -PT (TCP ping) or -PA (ARP ping) all require root. -PP, PE, PU all require root access because they require raw read-access to the echo replies.

While the documentation doesn't have a definitive list of what actions require root access, you can safely assume that almost every single one does because of the need for raw socket read access. This is the same principle as with REX sockets on low port numbers, where you need root privileges to reserve them. Pretty much the only reason why ping is the exception is because it doesn't use sockets in the first place. :man_shrugging:

My recommendation is that if the scan does not contain the -sn flag, then you should assume root is necessary, because any other default port scan will fall back to syn/tcp scans, which require root.

h00die commented 4 years ago

I thought -sT was ok. from my ubuntu on windows testing, it looks like it throws errors (i'd call them warnings technically), but still gets through it anyways.

The true answer is here: https://github.com/nmap/nmap/blob/master/NmapOps.cc#L498-L515 and it should be fairly simply to catch all those flags.

buzzdeee commented 4 years ago

just experienced the same Framework Version: 5.0.83-dev-bf8a1fc706

ignisc4t commented 4 years ago

for me, running sudo msfconsole fix the rest permission error on msf. tested on: android 7.1.2 running metasploit v6.0.2-dev (compiled from source)

and yes, I'm scanning my uncle school local network right now (my uncle the headmaster).

db_nmap -sS -Pn -A 192.168.1.1-255

running without issues, when at first I was use msf with normal user privilege, but sudo msfconsole fix it. it should do the work for the other system/OS too. hope it's help.

Script-Nomad commented 4 years ago

for me, running sudo msfconsole fix the rest permission error on msf.

Hey @enigm4s, thanks for the reply. While running msfconsole as sudo does suffice as a work-around, the main reason for this issue is to address msfconsole's inability to ask for permissions under the existing user context for privileged actions, such as with db_nmap. When you run msfconsole as sudo, the msfconsole process itself runs as root, rather than the original user context. Since this is the intent behind all the changes to MSF's security model and its insistence on not letting users install MSF as root, running msfconsole with sudo somewhat defeats the purpose.

The solution, as I envision it, would be something like a privilege-aware MSF which can intelligently request root privileges for these types of actions, rather than running MSF as root, and staying consistent with the intended security model.

ignisc4t commented 4 years ago

for me, running sudo msfconsole fix the rest permission error on msf.

Hey @enigm4s, thanks for the reply. While running msfconsole as sudo does suffice as a work-around, the main reason for this issue is to address msfconsole's inability to ask for permissions under the existing user context for privileged actions, such as with db_nmap. When you run msfconsole as sudo, the msfconsole process itself runs as root, rather than the original user context. Since this is the intent behind all the changes to MSF's security model and its insistence on not letting users install MSF as root, running msfconsole with sudo somewhat defeats the purpose.

The solution, as I envision it, would be something like a privilege-aware MSF which can intelligently request root privileges for these types of actions, rather than running MSF as root, and staying consistent with the intended security model.

yes, I do aware with that, hope it getting a full workaround from dev so there's no need to run/install msf as a root in the future. I guess because I use msf on this little phone and su wrapper didn't affect overall system environment. it'll be different in a bigger OS. yah, that's nuts

github-actions[bot] commented 4 years ago

Hi!

This issue has been left open with no activity for a while now.

We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 30 days since the last update here. If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.

radawson commented 3 years ago

It is still an issue in 6.0

githubismyresume commented 3 years ago

workaround for lack of sudo nmap in msfconsole

I'm hesitant to call this a workaround because I believe this method has multiple benefits, both in regards to solving the 'nmap needs sudo for scan xyz' problem, and in overall flexibility/robustness for your nmap needs. (in regards to Metasploit or otherwise)

db_nmap is a defacto alias for:

nmap {args} 0.0.0.0 -oX path/to/your/metasploit/postgres/db/goes/here

The ‘streamlined’ solution involves importing the xml output from all of your natural nmap scans you've been pissing off the neighborhood with. But, of course, you haven't actually beeen saving any of them as xml because you prefer to tab back and forth between chrome continuously to google 'what runs on port 445' as standard out scrolls by... lost in time like tears in the rain.

soo... unless a pull request involving meterpreter-ethereal-port-time-travel is released (I... I wouldn't actually be surprised) heres the next best thing.

mkdir nmap_scans

sudo nmap -v -A -oA nmap_scans/%D

((-oA outputs all filetypes supported by nmap, namely .nmap, .gnmap, and .xml))

———————————————————- ---back in your msfconsole tab------ ———————————————————-

db_import ~/nmap_scans/*.xml

I have a lot more to add but I've written too much already. I hope this helps.

bcoles commented 3 years ago

As a workaround, rather then run sudo msfconsole as suggested earlier in this thread, it is likely safer to give nmap cap_net capabilities, as suggested by the OP:

2. Alter Nmap capability permissions so that it can open raw sockets as underprivileged users

TL/DR:

# setcap cap_net_raw,cap_net_admin,cap_net_bind_service+eip /usr/bin/nmap
...
msf> db_nmap --privileged 127.0.0.1 -sS

Here's some cliff notes:

Note, this is still a workaround and doesn't resolve the issue in Metasploit, as:

Demo: Setting capabilities on a nmap executable:

[2020-11-22 00:57:37] root@kali:/# su - asdf
asdf@kali:~$ nmap -sS 127.0.0.1
You requested a scan type which requires root privileges.
QUITTING!
asdf@kali:~$ getcap /usr/bin/nmap
asdf@kali:~$ su
Password: 
[2020-11-22 00:57:48] root@kali:/home/asdf# setcap cap_net_raw,cap_net_admin,cap_net_bind_service+eip /usr/bin/nmap
[2020-11-22 00:58:07] root@kali:/home/asdf# 
exit
asdf@kali:~$ getcap /usr/bin/nmap
/usr/bin/nmap cap_net_bind_service,cap_net_admin,cap_net_raw=eip
asdf@kali:~$ nmap -sS 127.0.0.1
You requested a scan type which requires root privileges.
QUITTING!
asdf@kali:~$ nmap -sS 127.0.0.1 --privileged
Starting Nmap 7.91 ( https://nmap.org ) at 2020-11-22 00:58 EST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000030s latency).
Not shown: 998 closed ports
PORT    STATE SERVICE
80/tcp  open  http
111/tcp open  rpcbind

Nmap done: 1 IP address (1 host up) scanned in 0.15 seconds

Demo: Running a different nmap executable which doesn't have capabilities set with the --privileged flag:

asdf@kali:~$ /root/Desktop/nmap/nmap -sS 127.0.0.1
You requested a scan type which requires root privileges.
QUITTING!
asdf@kali:~$ /root/Desktop/nmap/nmap -sS 127.0.0.1 --privileged
Starting Nmap 7.91SVN ( https://nmap.org ) at 2020-11-22 01:00 EST
Couldn't open a raw socket. Error: Operation not permitted (1)
asdf@kali:~$

Alternatively, as @githubismyresume suggested above, it is often easier to run nmap outside of Metasploit, then import the logs with db_import, rather than use db_nmap within Metasploit. This is my usual workflow.

adfoster-r7 commented 3 years ago

Metasploit 6.0.27 will now detect if sudo is required for a particular nmap scan, and in such a scenario it will attempt to run the same command again with sudo prefixed:

image