Howdy folks!
Episode 195 of PaulDotCom Security Weekly prompted me to revisit an old favorite, netcat (many netcat versions exist). On the episode, Ed Skoudis provided an excellent technical segment on using netcat and netcat-like relays.
The write-up at PDC is very well done, but I thought I’d work my way through the examples, and try to illustrate with more text and some graphics. If you are following the notes on PDC, be advised I am using the term pivot synonymously with relay…
The goal of this post is to reinforce my own understanding of netcat by providing an informative introduction, and help readers who may not have familiarity with netcat develop an understanding of the possibilities the tool introduces.
Background
The simple netcat session consists of two steps:
- On one host, create a netcat listener on a specified port – sometimes referred to as the server
- On another host, create a netcat connection to the listener created in Step 1, sometimes referred to as the client
Once established, a netcat session provides bi-directional communication. Data going in one end, comes out the other. The session does not discriminate between ‘client’ and ’server.’ The only differentiator is that the listener is created first.
A fairly contrived networking example is provided below to illustrate netcat in use.
The version of netcat used in these examples is provided with BackTrack 4, and is slightly different than the version provided with some flavors of *Nix. But the basics are the same. If you are using Ubuntu - the -p when creating the listener is optional. Other than that, these command should work as written.
Example 1: Simple Netcat Session
Image may be NSFW.
Clik here to view.
Image 1: Simple Netcat Session
In this example, Host A and Host B want to communicate. Following the process described above, Host B creates a listener in Step 1, and Host A connects to that listener in Step 2.
A slightly more complicate example is provided in Example 2.
Example 2: Partial Pivot
Image may be NSFW.
Clik here to view.
Image 2: Partial Pivot
In Example 2, Hosts A and B can communicate, and B and C can communicate, but A and C cannot, directly.
If A wants to send data to C, we must pivot through B. We must use B as a relay between A and C.
This requires two netcat sessions. One between B and C, and another between A and B. Naturally, then, we need to set up two listeners (servers) and two talkers (clients).
The first session is established between B and C. This is done in Step 1 and the second part of Step 2.
Step 1) > nc -l -p 3333
Step 2.2) > nc 10.1.0.3 3333
The second session is created between A and B. This is done in the first part of Step 2 and in Step 3:
Step 2.1) > nc -l -p 2222
Step 3) > nc 10.1.0.2 2222
The key to making this pivot work, is that we must connect the output of the second session (between Host A and B) to the input of the first session (between Host B and C). This can be seen in the diagram’s Step 2. Host B issues the command to establish the listener for the communication with Host A using a pipe to send the output to the connection is it making to Host C.
> nc -l -p 2222 | nc 10.1.0.3 3333
This basically says, “listen for data coming in on 2222 and pipe it to port 3333 on host 10.1.0.3.
Perfect. Now all data sent to stdin on Host A will be sent through the pivot at Host B and to stdout on Host C.
The problem, however, is that Host A cannot see the results of whatever he sends through to C.
The challenge is that Host A’s output to B is being piped into a netcat session with C. Data coming back from C appears on the stdout of Host B! Host A never gets to see what is going on.
To remedy this, we must pipe the stdout coming from Host C to Host B to a place A can see it. If Host B has write access to a publicly accessible source (e.g., ftp server, wwwroot, etc) then problem solved. Or, we can create a third netcat session back from B to A!
Example 3: Two-way Pivot
Image may be NSFW.
Clik here to view.
Image 3: Two-way Pivot
This example extends the second example by simply providing one more netcat session back from stdin on B (coming from C) to Host A.
The stinky part is that Host A now has two terminal windows open:
- A session for sending the data through the pivot at B to C, and
- A session for receiving the results coming from C back through the pivot at B.
What we do gain, however, is that though Hosts A and C cannot talk directly, they can relay their communications through an intermediary set of hosts to accomplish the same task.
This method can be simplified.
As Ed pointed out in his Technical Segment, a shell redirect through a named pipe works quite well.
Example 4: Two-Way Pivot Using Named Pipe
Image may be NSFW.
Clik here to view.
Image 3: Two-Way Pivot Using Named Pipe
In Example 3, the relay, Host B, creates a named pipe, and then funnels the netcat input/output through the named pipe.
Host B issues the following two items on the command line:
> mknod bp p
> nc -l -p 2222 0<bp | nc 10.1.0.3 3333 1>bp
To analyze, let me label each part of this set of commands:
A) mknod bp p
B) nc -l -p 2222 0<bp
C) nc 10.1.0.3 3333 1>bp
D) B | C
A) mknod bp p
In step A, Host B creates a named pipe of type FIFO (p). A FIFO pipe works just like a FIFO queue – First In, First Out. This means that the first data arriving in the pipe will be the first data taken out of the pipe. This will allow us to create a writer and a reader attached to the queue. If you envision this as a line at a bank, the reader will be the bank teller, taking folks out of the queue, and the door to the bank acts as the writer, adding folks to the queue.
B) nc -l -p 2222 0<bp
In step B, the host creates a listener bound to port 2222, and uses input redirection to dump anything from the named pipe (bp) into the netcat session. When a client actually connects to this netcat session, the input will be written to stdout on Host B.
C) nc 10.1.0.3 3333 1>bp
In step C, the host creates a netcat session to host 10.1.0.3, where the output (stdout) arriving from the listener at the far end will be written into the named pipe (because of 1>bp).
What we can see now, is that the netcat listener in Step B is the reader from the FIFO queue, and the netcat session created in Step C is the writer to the queue. Perfect.
D) B | C
The final command D ties the two components together. Without using the pipe operator, the stdout arriving from Host A is still written to stdout on Host B. By using the pipe, we push stdout arriving from A into the netcat session created to Host C, just as we’ve done several times in these examples.
To illustrate the full data flow, then. Once both sets of netcat sessions are established as illustrated in Example 4, data flows through the system as follows. Data entered at Host A is sent over the netcat session to Host B where it is redirected through a pipe ( “|” ) into the netcat session Host B has created with Host C. As data comes back from Host C, it arrives at Host B, is written into the named pipe using output redirection (1>bp), where it is picked up by the netcat session Host B has with Host A because of input redirection (0<bp)
Conclusion
Skoudis goes into several deeper examples in the PDC Episode 195 show notes, and I encourage folks to read. It seems that your imagination, and the combination of your user access rights and a forgiving firewall rule-set are the only things limiting you!
The goals of this post are to:
- Strengthen my knowledge by educating;
- Assist those who may not have much exposure to netcat; and
- Help spark interest in the countless possibilities introduced!
I help you found it useful.
Bill