|
Softpanorama |
May the source be with you, but remember the KISS principle ;-)
|
| News | See Also | Recommended Books | Recommended Links | Recommended papers | Reference | Humor | Etc |
netcat is a network utility for reading from and writing to network connections on either TCP or UDP. It is designed in a thin and simple way, which makes it easy to incorporate in larger applications. Because of its versatility, netcat is also called the "TCP/IP Swiss Army knife".
The original version of netcat is a UNIX program. Its author is known only as *Hobbit*. A Windows version of netcat was created by Chris Wysopal.
Fully POSIX compatible rewrite from scratch is known as GNU Netcat. It is maintained by Giovanni Giacobbi.
|
Netcat - The TCP/IP Swiss Army Knife
Tom Armstrong
February 15, 2001Overview
Netcat is a tool that every security professional should be aware of and possibly have in their ‘security tool box’. In May/June of 2000, insecure.org conducted a survey of 1200 Nmap users from the Nmap-hackers mailing list to determine their favorite security tools. Netcat was the second most popular tool, not including Nmap. A quick search on securityportal (www.securityportal.com) found 166 matches of netcat. Most of the matches describe or use netcat in some way. Netcat is a utility that is able to write and read data across TCP and UDP network connections. If you are responsible for network or system security it essential that you understand the capabilities of netcat.
Netcat should not be installed unless you have authority to do so. Never install any executable unless you can trust the providor. If possible review the source and compile it yourself. To be safe only use netcat in a test environment.
Hobbit (hobbit@avian.org) created netcat in 1995 as a feature-rich network debugging and exploration tool. Its purpose was to be able to create just about any type of network connection. According to Hobbit-
Some of the features of netcat are:
- Outbound or inbound connections, TCP or UDP, to or from any ports
- Full DNS forward/reverse checking, with appropriate warnings
- Ability to use any local source port
- Ability to use any locally-configured network source address
- Built-in port-scanning capabilities, with randomizer
- Built-in loose source-routing capability
- Can read command line arguments from standard input
- Slow-send mode, one line every N seconds
- Optional ability to let another program service inbound connections
Some of the potential uses of netcat:
- Script backends
- Scanning ports and inventorying services
- Backup handlers
- File transfers
- Server testing and simulation
- Firewall testing
- Proxy gatewaying
- Network performance testing
- Address spoofing tests
- Protecting X servers
- 1001 other uses you`ll likely come up with
The original version of netcat was released to run on Unix and Linux. Weld Pond (weld@l0pht.com) released the Windows NT version in 1998. The source code is available for both versions.
Remote command prompt anyone?
On a Windows NT server issue the following command in the directory that contains netcat:
nc -l -p1234 -d -e cmd.exe –L
This –l puts netcat into listen mode, the -p1234 tells netcat to use port 1234, the –d allows netcat to run detached from the console, the –e cmd.exe tells netcat to execute the cmd.exe program when a connection is made, and the –L will restart Netcat with the same command line when the connection is terminated.
On the client system issue the following command:
nc destination 1234
This command causes netcat to connect to the server named destination on port 1234. Immediately you are given a console connection to the destination server. Be careful! To exit the remote console session type:
exit
You will be returned to your own console and will be able to reconnect to the destination server because netcat was started on the destination server with the –L option.
FTP & drive mapping blocked?
To receive a file named newfile on the destination system start netcat with the following command:
nc –l –p 1234 >newfile
On the source system send a file named origfile to the destination system with the following command:
nc destination 1234 <origfile
Issue a ^C on the source system and your done. Be sure to check the file to be sure it is the same size as the original.
Hiding Netcat on Windows NT
Here are a few ways that a hacker could use to hide netcat on a system or use it behind a firewall:
- Rename the executable or recompile with a different name. Beware that using a copy of netcat that you aren’t sure how the source was compiled is very dangerous. If possible review the source code and compile it yourself.
- Detach from the console option (-d)
- Use a port that is well known and allowed through any firewalls between the two systems.
Port Scanning
A scanning example from Hobbit is "nc -v -w 2 -z target 20-30". Netcat will try connecting to every port between 20 and 30 [inclusive] at the target, and will likely inform you about an FTP server, telnet server, and mailer along the way. The -z switch prevents sending any data to a TCP connection and very limited probe data to a UDP connection, and is thus useful as a fast scanning mode just to see what ports the target is listening on. To limit scanning speed if desired, -i will insert a delay between each port probe. Even though netcat can be used for port scanning it isn’t its strength. A tool such as nmap is better suited for port scanning.
Netcat + Encryption = Cryptcat
Netcat is a useful tool as it is, but if someone were using it you would be able to at least get a feel for what they were doing. At least you could before Cryptcat! Cryptcat is the standard netcat enhanced with Bruce Schneier’s twofish encryption. It can be found at www.farm9.com. Linux, OpenBSD, FreeBSD, and Windows versions are available. So much for sniffing any netcat traffic!
Command Option Overview
Netcat accepts its commands with options first, then the target host, and everything thereafter is interpreted as port names or numbers, or ranges of ports in M-N syntax. Netcat does not currently handle portnames with hyphens.
Option
Description
-d
Allows netcat to detach from the console on Windows NT. -e
Executes a program if netcat is compiled with the –DGAPING_SECURITY_HOLE.
-i
Sets the interval time. Netcat uses large 8K reads and writes. This basically sends data one line at a time. This is normally used when data is read from files or pipes. -g
Used to construct a loose-source-routed path for your connection. This is modeled after "traceroute". -G
Positions the "hop pointer" within the list. -l
Forces netcat to listen for an inbound connection. An example "nc –l –p 1234 <filename" tells netcat to listen for a connection on port 1234 and once a connection is made to send the file named filename. The file is sent whether the connecting system wants it or not. If you specify a target host netcat will only accept an bound connection only from that host and if you specify one, only from the specified foreign source port. -L
Restarts Netcat with the same command line that was used when the connection was started.. This way you can connect over and over to the same Netcat process. -n
Forces netcat to only accept numeric IP addresses and to not do any DNS lookups for anything -o
Used to obtain a hex dump file of the data sent either way, use "-o logfile". The dump lines begin with "<" or ">" to respectively indicate "from the net" or "to the net", and contain the total count per direction, and hex or ascii representations of the traffic. -p
Required for outbound connections. The parameter can be numeric or a name as listed in the services file. If –p is not used netcat will bind to whatever unused port the systems gives it, unless the –r option is used. -r
Causes port scanning to be done randomly. Normally it is done highest to lowest. -s
Used to specifiy local network source address. Usage "-s ip-addr" or "-s name". -t
Enables netcat to respond to telnet option negotiation if netcat is compiled with –DTELNET parameter. Telnet daemons will get no useful answers, as they would from a telnet program. -u
Tells netcat to use UDP instead of TCP. -v
Controls the level of verbosity.
- (without –n) netcat will do a full forward and reverse name and address lookup for the host, and warn you about the all-to-common problem of mismatched names in the DNS.
- Usually want to use the –w 3, which limits the time spent trying to make a connection.
- If multiple ports are given –v must be specified twice.
-w
Limits the time spent trying to make a connection. -z
Prevents sending any data to a TCP connection and very limited probe data to a UDP connection. Use –i to insert a delay between each port probe. This is useful as a fast scanning mode just to see what ports the target is listening on. Conclusion
Netcat is a powerful tool that every security professional should be familiar with. It should be used with caution. I would not recommend installing netcat on your production networks. I would suggest using it to test your firewall, and router configurations in a test environment. It can also be used to test your operating system lockdown procedures. Be certain that you have the authority to install and use netcat on your network before doing so. You might even want to review the source code to learn how Hobbit built netcat and how Weld Pond ported it to the Windows platform.
References
1. Insecure.org, "Top 50 Security Tools"
URL: http://www.insecure.org/tools.html (August 21, 2000)2. Hobbit, "New tool available: Netcat"
URL: http://lists.insecure.org/bugtraq/1995/Oct/0028.html (October 28, 1995)3. Weld Pond, "Netcat 1.10 for NT"
URL: http://www.l0pht.com/~weld/netcat/readment.txt (February 2, 1998)4. Hobbit, "Netcat 1.10"
URL: http://www.l0pht.com/~weld/netcat/readme.html (March 20, 1996)5. Farm9, "cryptcat = netcat + encryption"
URL: http://farm9.com/content/Free_Tools/Cryptcat (October 2, 2000)6. Hobbit, "Netcat 1.10"
URL: http://www.l0pht.com/~weld/netcat/readme.html (March 20, 1996)
Netcat is a featured networking utility which reads and writes data across network connections, using the TCP/IP protocol. It is designed to be a reliable "back-end" tool that can be used directly or easily driven by other programs and scripts. At the same time, it is a feature-rich network debugging and exploration tool, since it can create almost any kind of connection you would need and has several interesting built-in capabilities.
It provides access to the following main features:
- Outbound and inbound connections, TCP or UDP, to or from any ports.
- Featured tunneling mode which allows also special tunneling such as UDP to TCP, with the possibility of specifying all network parameters (source port/interface, listening port/interface, and the remote host allowed to connect to the tunnel.
- Built-in port-scanning capabilities, with randomizer.
- Advanced usage options, such as buffered send-mode (one line every N seconds), and hexdump (to stderr or to a specified file) of trasmitted and received data.
- Optional RFC854 telnet codes parser and responder.
netcat could forward data stream from stdin to a TCP or UDP socket, and from a TCP or UDP socket to stdout. Just like the
catprogram to forward data from stdin to stdout. According to unconfirmed sources, that's the origin of the netcat program name.
/usr/bin/yes generates stream of yzw@q ~ % yes y y y y y y yPress
ctrl-Cto stop the y's. You can generated stream on no too.zw@q ~ % yes no no no no no noThe hub (hub.c) and cable (cable.c) utilities are certainly inspired by netcat which could forward data stream from a socket to stdout, and from stdin to a socket. Did I forget to recommend the netcat companion documentation for you to read? ;-) Hub is designed to be like a server, and cable is designed to be like a client. Instead of forwarding data between stdin/stdout and a socket, hub and cable forward and multiplex data from a socket to any other sockets. That's where the names come from. They're just like Ethernet hub and cable. Lets' see a screenshot. Yeah, screenshot! ;-)
zw@q ~ % ./hub lullaby internetworks lab: (server alike) hub $Revision: 1.2 $ Copyright (C) 2001 zhaoway <zw@debian.org> Usage: hub [hub buffer size] [tcp port number] [number of hub ports] o hub buffer size is in bytes. for example 10240. o tcp port number is at least 1024 so i do not need to be root. o number of hub ports is at least 2. happy. zw@q ~ %Hub will listen on a TCP port simulating a many port Ethernet hub. Data come in from one hub port will be forwarded to other hub ports. You could test the hub alone without cable using netcat. Note: nc is the acronym for netcat.
- Launch hub in the console A:
ConA % ./hub 10240 10000 2- From console B, connect a netcat:
ConB % nc localhost 10000- From console C, connect another netcat:
ConC % nc localhost 10000- Then you could type in ConC and read the output in ConB, vice versa.
Then there is cable:
zw@q ~ % ./cable lullaby internetworks lab: (client alike) cable $Revision: 1.2 $ Copyright (C) 2001 zhaoway <zw@debian.org> Usage: cable [cable buffer size] [1st ip] [1st port] [2nd ip] [2nd port] .. o cable buffer size is in bytes. for example 10240. o ports should be listening or connection attempts will fail. o number of ip addr and port pairs is at least 2. zw@q ~ %Cable is more or less like a shared Ethernet bus coaxial cable. It forwards and multiplexes data between listening socket daemons. Let's test it too.
- Launch a netcat daemon in ConA:
ConA % nc -l -p 10000- Launch another netcat daemon in ConB:
ConB % nc -l -p 10001- Arrange the cable:
ConC % ./cable 10240 127.0.0.1 10000 127.0.0.1 10001- Then you could type in ConA and read the output from ConB, vice versa.
There are some interesting techniques used in developing hub and cable. Notably the
select()function call. But for now, we will focus on our course to reinvent the/usr/bin/yesfirst. ;-)It's not a very easy task to reinvent
/usr/bin/yesusing netcat and hub and cable. I could only give a cheat answer. And that's why I need to set the buffer size command line argument. But anyway, let's begin!The main idea is as following. First we set up a three-port hub, then we using cable to connect two hub port together, after that we could using netcat to echo any character into the remain free hub port. It's like the following diagram:
| cable \|/ ,---------, | | | V V V ,--[ ]-------[ ]-------[ ]--. | A B C | | three-port hub | `---------------------------'Because the nature of the hub, data sent in from port A, will be forwarded to port B and port C, since port B and C are connected by a cable, the data come out of the hub will go right back in, and then being multiplexed and forwarded to port A and circulating in the cable loop to eternity. Eventually port A will receive infinite copies of the original data sent in.
Lets' construct the device.
- In ConA, we launch the three-port hub:
ConA % ./hub 10240 10000 3- In ConB, we loop the cable:
ConB % ./cable 10240 127.0.0.1 10000 127.0.0.1 10000Now after we finished construction of our device, then we will using netcat to finally finish our reinvention of
/usr/bin/yes.ConC % echo "y" | nc localhost 10000 y y y y y yThe tricky exercises left for the reader is: what if we change the buffer size of both cable and hub from 10240 to 1? You could try and see for yourself.
Have fun and good luck!
Recommended Links
Netcat - Wikipedia, the free encyclopedia
The GNU Netcat -- Official homepage
ONLamp.com Netcat and Reverse Telnet
Play with the Lovely Netcat LG #74
freshmeat.net Project details for netcat
Wonders of 'dd' and 'netcat' Cloning OS harddrives
The GNU Netcat -- Official homepage
The GNU Netcat -- Official homepage -- Downloads
freshmeat.net Project details for netcat SecurityFocus also hosts the Windows version of Netcat.
Copyright © 1996-2007 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
Standard disclaimer: The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: February 28, 2008