DSNIFF

Dsniff is a collection of free tools that were originally written for network and penetration testing, but that can be used for evil to sniff and hijack network sessions.

Installation

Dsniff is available from http://www. monkey .org/~dugsong/dsniff/. It requires several other packages, including OpenSSL, libpcap, Berkeley DB, libnet, and libnids. You should be able to find binary versions of these packages for your particular Unix OS with relative ease.

Tip 

When downloading the third-party packages, libpcap must be installed before libnet, and libnet must be installed before libnids.

Dsniff builds like any other Unix application ( configure , make , make install ). When you're done installing, dsniff will, by default, place all its tools in /usr/local/sbin.

Note 

A Windows port of an older version of dsniff (1.8 as opposed to 2.3) is available at http://www.datanerds.net/~mike/dsniff.html, but we will be strictly using the original Unix version for this section.

Implementation: The Tools

As mentioned, dsniff is actually a collection of various tools. We'll take a brief look at each individual tool, what it can do, and how it can be used for both good and evil purposes.

Arpspoof

We've talked about how network switches make sniffing more difficult because the switch is smart; it knows the Ethernet MAC address of every machine on every port, so only the destination machine receives the packet. However, sniffing on switched networks is still possible by forging ARP replies for the destination host. Arpspoof allows us to do that.

You'll recall that ARP is the protocol used to map an IP address to Ethernet MAC addresses. Because ARP requests are broadcast to the entire network (as in, "Hey everyone, which of your Ethernet cards has an IP address of 192.168.1.100?"), they will always go out to everyone. The host running arpspoof can tell the issuer of the ARP request that it has the IP address in question, even if it doesn't. You can fool the ARP request host and the switch into sending the packet to you instead of the intended recipient. You can then make a copy of the packet and use a packet forwarder to send the packet on to its intended destination like a relay.

The command-line usage of arpspoof is arpspoof host_to_snarf_packets _from . You can specify which network interface to use with the -i option, and you can specify particular hosts you want to lie to by using the -t option. By default, arpspoof forges the MAC address of host_to_snarf_packets_from to all hosts on the LAN. The most popular host on a LAN to ARP spoof is the default router. Because all LAN traffic will pass through the router to get to other networks, ARP spoofing the router lets you sniff everything outbound on the LAN! Just don't forget to set up IP forwarding so that the router still gets the packet; otherwise , your entire LAN loses its Internet connection! In the following example, we're enabling IP forwarding on our Linux box (this has to be compiled into the kernel first) and trying to ARP poison 192.168.1.245 into thinking that we (192.168.1.100) are the default gateway (192.168.1.1).

 # cat /proc/sys/net/ipv4/ip_forward 0 # echo 1 > /proc/sys/net/ipv4/ip_forward # arpspoof -t 192.168.1.245 192.168.1.1 & # arpspoof -t 192.168.1.1 192.168.1.245 

The first command checks to make sure the Linux kernel was compiled with IP forwarding. If this file does not exist, you'll have to rebuild your kernel with IP forwarding. The second command enables the IP forwarding. The third command says that we should tell 192.168.1.245 that we're 192.168.1.1 so that he'll send all of his Internet-bound traffic through us. The fourth command says that we should tell the gateway that we're him! If we don't do this, we'll be able to snoop only on the outgoing trafficnot the incoming traffic.

Dnsspoof

This tool works similarly to arpspoof. It lets you forge DNS responses for a DNS server on the local network. Because DNS runs on User Datagram Protocol (UDP), a connectionless protocol, a DNS client will send out a query and expect a response. The dnsspoof tool will simply forge a response (telling the client that the hostname resolves to its IP) and attempt to get it there before the real response from the intended DNS server arrives. Dnsspoof can forge responses for all DNS queries it receives, or you can create a file in hosts(5) format (called spoofhosts , for example) that resolves only specific names to your local IP address and then run dnsspoof with the -f spoofhosts option to have it lie about only these specific IP-host mappings. An example spoofhosts file is shown next (192.168.1.100 is the address of the machine running dnsspoof):

 192.168.1.100     mail* 192.168.1.100     www* 

This file tells dnsspoof to forge DNS responses only for hostnames beginning with mail or www instead of forging responses to every DNS query it intercepts.

Other than the same -i option that arpspoof takes to specify a network interface, the only argument dnsspoof takes is a tcpdump packet-filter expression for sniffing. It will use that expression to find any DNS traffic so that it can forge responses to any incoming queries on the LAN that it can see. If you first use arpspoof to spoof the MAC address of the intended DNS server, you can ensure that dnsspoof will always receive the DNS queries for the LAN and will always be able to respond with spoofed hostname/IP mappings. In the next example, 192.168.1.5 is the DNS server and 192.168.1.245 is once again our victim.

 # echo 1 > /proc/sys/net/ipv4/ip_forward # arpspoof -t 192.168.1.245 192.168.1.5 & # arpspoof -t 192.168.1.5 192.168.1.245 & # dnsspoof -f spoofhosts host 192.168.1.245 and udp port 53 

The first few commands set up the same bidirectional ARP spoofing that we used in the previous section. It allows us to fool 192.168.1.245 into thinking that we're the DNS server. The final command listens for DNS traffic involving 192.168.1.245, and any queries for hosts beginning with www or mail will be answered with an IP address of 192.168.1.100. Other DNS queries should be ignored and passed through to the real DNS server. So if 192.168.1.245 points his web browser at http://www.yahoo.com, he'll actually be talking to the web server running on our machine, 192.168.1.100. Notice that we've been careful to specify the host 192.168.1.245 in our dnsspoof command. If we leave this out, dnsspoof will attempt to forge a DNS response to every DNS request it snoops , which is not what we want in this case.

Arpspoof and dnsspoof allow you to masquerade as different machines on a network. The benefits are obvious for malicious hackers, but can these two tools be used for good? Of course! In addition to network and firewall testing, system administrators could use the masquerading techniques to create a type of honeypot for potential "insider" hackers. You could set up arpspoof and dnsspoof so that a visit to a popular hacking and vulnerability web site actually went to a bogus site under your control. The bogus site looks much like the real site, except the bogus site tells the tale of a simple exploit for a critical system you're running. Of course, this tale is completely fabricated and won't harm your system at all, but you can sit back and see whether anyone tries this bogus exploit against you. If someone does, you've found yourself a troublemaker.

The dsniff tool is an advanced password sniffer that recognizes several different protocols, including TELNET, FTP, SMTP, Post Office Protocol (POP), Internet Message Access Protocol (IMAP), HTTP, CVS, Citrix, Server Message Block (SMB), Oracle, and many others. Whereas other sniffers such as Ethereal will give you tons of additional information about the connection and the individual packets, you use dsniff if all you want are usernames and passwords.

Command-line Flags The following table shows the command-line flag options and explanations .

Option	Explanation
-c	Turns on half-duplex TCP stream assembly to allow correct sniffing operation when using arpspoof
-d	Starts debugging mode
-f <file>	Loads triggers (i.e., types of services to password sniff for) from a file with an /etc/services format
-i < if>	Uses a specific network interface
-m	Uses the dsniff.magic file to attempt to determine a protocol automatically using characteristics defined in the magic file
-n	Performs no host lookups
-r <file>	Reads sniffed data from a previously saved session (see -w )
-s <len>	Snarfs at most first <len> bytes of the packet, which is useful if the username and password information come after the default 1024-byte limit
-t <trigger>	Loads a comma-delimited set of triggers using the format port/proto=service ; for example, dsniff t 23/tcp=telnet, 21/tcp=ftp,110/tcp=pop3 will perform password sniffing for telnet, FTP, and SMTP sessions
-w <file>	Writes sniffed data to a file in Berkeley DB format for later analysis (using dsniff -r )

Usage and Output The only other argument that dsniff can use is a tcpdump packet-filter expression so that you can specify what kind of traffic you want to sniff for passwords.

Let's run dsniff to see whether our friend bob logs into something:

 [root@originix sbin]# dsniff -t 21/tcp=ftp,23/tcp=telnet -n Kernel filter, protocol ALL, raw packet socket dsniff: listening on eth0 [] ----------------- 03/23/02 09:40:50 tcp 192.168.1.101.3482 - 192.168.1.100.21 (ftp) USER bob PASS bob123 ----------------- 03/23/02 09:41:52 tcp 192.168.1.101.3483 - 192.168.1.100.23 (telnet) root guessme jdoe password ls 

There's bob. He FTP'ed in and we grabbed his password. But what about the telnet session below it? Dsniff appears to have captured an attempted root login via telnet. The login seems to have been unsuccessful , because it appears the user then tried logging in as jdoe with the password password and got into the system. Dsniff then recorded the ls command being executed. Now, most systems don't allow root access via telnet even if the correct password is provided. The password guessme could very well be the root password. And because we now know jdoe's password, we can get on the system and give it a try.

Had jdoe attempted an su to root later in the connection, dsniff would have caught that, too. That's why dsniff captures subsequent commands as well as login information from the telnet session. You'll notice that dsniff waits until a connection terminates before it outputs its information. This is in case it detects any other useful username/password information somewhere other than in the initial login.

Filesnarf

Tcpdump can be used to sniff NFS traffic. The filesnarf tool can actually take the sniffed file and reassemble it on your system. Anytime someone moves a file via NFS over the network, you can grab a copy of it, even if the NFS export isn't available to you.

Again, you can use the i option to specify the network interface. On the command line, you can also specify a tcpdump packet-filter expression to use for sniffing NFS traffic and the file pattern to match (only snarf *.conf files or snarf files called passwd ). If you want to snarf all files except certain files (say, you want to snarf everything except MP3 files), you can invert the file pattern matching with v like so:

 # filesnarf -v '*.mp3' 

And if you wanted to snarf only non-MP3 files from 192.168.1.245, you would use this:

 # filesnarf -v '*.mp3' host 192.168.1.245 

Macof

The macof tool will flood the local network with random, conjured MAC addresses in the hopes of causing a switch to fail and start acting like a hub, allowing dsniff to have more success in a switched network environment. You can run macof by itself to generate random TCP/IP traffic with the random MAC addresses, or you can specify the type of traffic using command-line flags. You can control the network interface used ( -i ), the source and destination IP address ( -s and -d ), the source and destination port ( -x and -y ), a single target hardware address ( -e ), and the number of made-up packets to send ( -n ).

Mailsnarf

As filesnarf does for NFS, mailsnarf reassembles sniffed e-mail messages from SMTP and POP protocols. It saves the messages in standard mbox format so that you can browse them as you would any Unix mailbox using mutt, pine, or whatever Unix mail application you choose. The options are exactly the same as filesnarf, except instead of specifying file pattern matching, you specify regular expressions to be matched in the header or body of the message.

Msgsnarf

Like the other snarf programs, msgsnarf does the same thing for popular chat programs such as AOL Instant Messenger, Internet Relay Chat (IRC), ICQ, and MSN and Yahoo!'s messenger utilities. In this case, you can specify a regular expression pattern to search for in the messages (such as saving only messages that contain the word password in them). Here we've intercepted a message from cauliflowericious to broccoliastic.

 # msgsnarf "password" msgsnarf: listening on ep0 Aug 18 16:07:11 AIM cauliflowericious > broccoliastic: <FONT COLOR=\"#000000\"> Yeah, just log in to http://www.my server.com/myprivatefiles/. My password is iLuvVeggies. You can use them for as long as you want. </FONT>" 

Sshmitm

Sshmitm is one of the nastier tools that comes with dsniff. Assuming you're running dnsspoof to forge the hostnames of a real machine, sshmitm (which stands for "SSH Monkey in the Middle") can sniff the SSH traffic redirected to your machine. It supports only SSH version 1 (a good reason to upgrade to version 2).

How is this done? The dnsspoof tool lets us intercept an SSH connection to another machine. All we have to do is start sshmitm on port 22 (we can change the port sshmitm uses with the -p option) and set it up to relay the SSH connection to the true host. If we're running dnsspoof to tell people that we're host foohost when actually 192.168.1.245 is foohost, when somehost does an SSH to foohost, it looks up foohost first and finds it at our forged IP address. So if we run the command sshmitm p 22 192.168.1.245 22 , we can intercept the SSH connection from somehost before passing it on to foohost. What does this buy us? When SSH negotiates the keys to use for encrypting the data, sshmitm can intercept the key from somehost and replace it with a key that we know about. This will allow us to decrypt all information in the hijacked connection.

Tcpkill

This tool attempts to kill a TCP connection in progress by spoofing a reset (RST) packet and injecting it into the legitimate connection. As with many of the other tools, the -i option will choose your interface and a tcpdump packet-filter expression can be used to select the type of connections you want to kill. An additional option, - num , where num is any number from 1 through 9, tells tcpkill how hard it needs to try to kill the connection. Faster connections may be more difficult to inject packets in than slower connections. The default "kill" level is 3 .

Tcpnice

So maybe you don't want to kill a connection completely. Tcpnice will let you just slow it down a bit. You use the same options used in tcpkill, except instead of trying to inject RST packets with a varying level of severity, you use the -n increment option to specify how much you want to slow down the connection. An increment of 1 is the default speed and an increment of 20 is the slowest speed. The tool performs this slowdown by adjusting the amount of data that hosts say they can handle.

Part of the TCP header is the window size, which allows a host to advertise the maximum amount of data it can handle. The tcpnice tool sniffs the traffic matching your tcpdump packet-filter expression and alters the value of the window size advertisement to be smaller than it really is. You use the -n flag to adjust how much smaller the window is made. This will tell the host on the other end of the conversation that it needs to stop sending so much data so quickly, and the connection will slow down. To add fuel to the fire, you can use the I option to forge ICMP source quench replies to make the host on the other end think that it's flooding the host with more data than it can handle. This can cause the connection to slow down even more.

Urlsnarf

Urlsnarf works just like all the other snarf programs in this tool kit, except it works on web URLs. It stores any URLs it sniffs from HTTP traffic into a logfile that can be analyzed later. It's a quick and easy way to see what the people on your local network are looking at when they surf the Web.

Webmitm

This tool does for HTTPS (SSL-enabled web traffic) what sshmitm does for SSH. It requires the use of dnsspoof and operates in the same manner, interjecting a fake SSL certificate (that will allow the "monkey in the middle") to decrypt all data that we pass back and forth. The one drawback here is that the user might be notified by the web browser that the certificate for a particular site has changed. Many users will ignore this message, however, and continue with the session.

Webspy

This final tool in the dsniff package is a bit frivolous. By specifying an IP address of a host on your LAN, webspy will sniff for web traffic originating from that host. Whenever that host surfs to a particular URL, webspy will load the same URL on your Netscape browser. All you need to do is have your Netscape web browser running before starting webspy. See exactly what your friend down the hall is surfing. Talk about an invasion of privacy!

Dangerous Tools

As you can see, some extremely dangerous tools have been outlined here. Although the tools' author genuinely intended them for good use, it's quite obvious that hackers could use these tools to sniff all kinds of secret information that doesn't belong to themeven information that's supposed to be encrypted! The drawback is, of course, as with any sniffer, you need to be on the same local network as your victim. Tools like this should make every network security manager think twice about trusting internal users.