Linux sysadmins: Understand ncat's power to avoid accidental security risks
ncat command is part of the nmap suite and was written specifically for it. It's true that
ncat has as many uses as the famed Swiss Army knife, but it can be as equally dangerous when incorrectly used or when used by malicious actors. One of its strengths is that
ncat can be both client and server. This article focuses on one aspect of that relationship. I show you how to open a listening bash shell with
ncat that anyone can access with
ncat as a client. In my article, Linux troubleshooting: Setting up a TCP listener with ncat, I describe how to set up
ncat as a listener or server that listens on a specific port. This example is similar, but I think you'll be impressed with the sheer power that
ncat gives you. It should also scare you—a lot.
Check your system under
/usr/bin first to see if you need to install
ncat. It is typically included in any Red Hat Enterprise Linux-based distribution. If you find that you need to install it, the package name is
nmap-ncat. You either can install
ncat by itself or install
nmap and the
nmap-ncat package installs as a dependency.
ncat commands as root, especially for the examples in this article. Doing so will allow anyone to have root access to your system without authentication. Any user can issue
ncat commands, which is one of its features as well as one of its dangers. I suggest that you create a service account and work with
ncat using that account. Trust me, I've heard every argument for and against service accounts, but once you see
ncat in action, you'll want to use the service account for interactions with it.
Deliver a bash shell
This is the fun (and dangerous) part of using
ncat. Switch user to your new service account. I've named mine bashful.
[ken@server1 ~] $ su - bashful
[bashful@server1 ~] $
Now that you've switched user accounts, it's time to open that shell. It gives unauthenticated access to your system via a mostly interactive shell. You'll see what I mean by "mostly" interactive once you connect. This next command uses
ncat to execute a bash shell that listens on a TCP port. For this example, I'm using port 9922 on server1 (192.168.1.50). The
-l option sets up a listening port. The
-k option is a keepalive flag, which maintains the socket. If you don't issue the
-k option, then the socket dies after you disconnect the session, and no other connections can be made to it.
[bashful@server1 ~] $ ncat -e "/bin/bash" -l 9922 -k &
-e option executes the command in quotes, which in our case is the bash shell (
/bin/bash). I use the ampersand (
&) after the command to release my prompt and put the
ncat listener into background mode. If you don't use the
&, then your terminal will "hang" and not allow you to interact with it. If that's not a problem for you, then leave it as is.
netstat command shows that the listener is in place.
[bashful@server1 ~]$ netstat -an |grep 9922
tcp 0 0 0.0.0.0:9922 0.0.0.0:* LISTEN
tcp6 0 0 :::9922 :::* LISTEN
To connect to the listening port from a remote system, you also have to open an exception in the host-based firewall for port 9922.
[ken@server1 ~]$ sudo firewall-cmd --add-port=9922/tcp
Do you see the failsafe here? It's the firewall exception that I had to create using my account and
sudo. If you have a host-based firewall or IPTables running (and you'd better have), then this service won't work until you allow that port, which means that no ordinary user can make this work without administrative access. Otherwise, ncat-educated users would be opening ports all over the place and driving you crazy in the process. Not to mention the security issues you'd have. I digress.
Access the shell from a remote system
Now you can access the bash shell from a remote system on port 9922.
[ken@server2 ~]$ ncat 192.168.1.50 9922
From server2, issue the
ncat command with the target IP address of server1 and the listening port 9922. Once you're connected, nothing happens, or so you might believe because the terminal seems to sort of hang. But what's really happening is that you're communicating with the raw socket and therefore, will not see a prompt. Prove it by issuing the
[ken@server2 ~]$ ncat 192.168.1.50 9922
ken pts/0 2020-08-26 13:39 (server2)
You can issue any command you wish that user bashful has access to. If you issue a command that requires root access, you will likely not see a response. The terminal will appear to stay in the "hung" state. Your response will actually appear on the terminal of server1. For example, if you issue the following command:
You see nothing on server2's screen. On server1's screen, the following appears:
[bashful@server1 ~]$ Authorization failed.
Make sure polkit agent is running or run the application as superuser.
To disconnect from server2's clandestine shell, issue the Ctrl+C combination and your local prompt returns.
Don't try this at work
Just for fun, or if you don't believe me, kill the current
ncat process using your service account or as root. Then re-issue the same command as the root user to execute that bash shell as root. Connect again from a remote system and re-issue that firewall command. This time you'll see the results. You can issue any command as root, which is why you never want to set up this type of service as the root user.
And now you see the real danger of using
ncat as root. Malicious actors will set up such a shell on a clandestine port that's missed by a port scan and have full root access without authentication.
The very useful and potentially very dangerous
ncat command is your best friend and your worst enemy. Like every other tool in the shed, it has no intent other than what you give it. You should study the
ncat command, its uses, and its limitations in your environment. Remember to kill any
ncat process that you don't want to continuously run once you're finished with it and remove the firewall exception that allows its access. Also, remember that with great power comes the ability to really screw things up.
[ Want to test your sysadmin skills? Take a skills assessment today. ]