Closed Script-Nomad closed 3 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.
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?
Is there any new about it? I have had the same problem.
I need to perform scans that requires privileges
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.
@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.
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.
just experienced the same Framework Version: 5.0.83-dev-bf8a1fc706
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.
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.
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
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.
It is still an issue in 6.0
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 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.
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:
db_nmap
will require users to provide the --privileged
flag to nmap
even when capabilities are setDemo: 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.
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:
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:
sudo msfconsole
(a workaround) that would violate the security model's intentThings 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.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
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
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.