Penetration Testing with dsniff
Christopher R. Russel
February 18, 2001
What is dsniff?
The ability to access the raw packets on a network interface (known as network sniffing), has long been
an important tool for system and network administrators. For debugging purposes it is often helpful to
look at the network traffic down to the wire level to see exactly what is being transmitted. Dsniff, as the
name implies, is a network sniffer - but designed for testing of a different sort. Written by hacker Dug
Song, dsniff is a package of utilities that includes code to parse many different application protocols and
extract interesting information, such as usernames and passwords, web pages being visited, contents of
email, and more. Additionally, it can be used to defeat the normal behaviour of switched networks and
cause network traffic from other hosts on the same network segment to be visible, not just traffic involving
the host dsniff is running on.
These capabilities alone are enough to attract interest, but in its latest version (2.3 as of this writing,
released late December 2000), it includes new programs to launch man-in-the-middle attacks on the SSH
and HTTPS protocols, which would allow viewing of the traffic unencrypted, and even the possibility of
taking over interactive SSH sessions. These new abilities have caused some uproar in the security
community, however this document is not an ethical or technical debate; I only hope to show dsniff in
action to help people understand its capabilities and therefore be better able to see weaknesses in their
own network.
The dsniff Package
To give you an idea of exactly what dsniff can be used for, here is a list of tools included in the dsniff
package, and a brief description of their function, partially taken from the dsniff README:
arpspoof
redirects packets on a LAN to defeat the host-isolating behaviour of the switch.
dnsspoof
forges replies to DNS queries.
dsniff
password sniffer with ability to handle FTP, Telnet, SMTP, HTTP, POP, poppas,
NNTP, IMAP, SNMP, LDAP, Rlogin, RIP, OSPF, PPTP MS-CHAP, NFS, VRRP,
YP/NIS, SOCKS, X11, CVS, IRC, AIM, ICQ, Napster, PostgreSQL, Meeting Maker,
Citrix ICA, Symantec pcAnywhere, NAI Sniffer, Microsoft SMB, Oracle SQL*Net,
Sybase and Microsoft SQL authentication info.
filesnarf
saves files sniffed from NFS traffic.
macof
causes LAN switch to fail-open (ie. Act as a hub and broadcast traffic to all hosts).
mailsnarf
saves email messages sniffed from SMTP and POP traffic.
msgsnarf
saves messages and chat sessions sniffed from most Instant Messenger protocols
and IRC.
tcpkill
kills specified in-progress TCP connections.
tcpnice
slows down specified TCP connections.
urlsnarf
reports URLs sniffed from HTTP traffic.
webspy
sends sniffed URLs to your local Netscape browser, allowing you to browse in realtime along with the target.
sshmitm
proxies and sniffs SSH traffic redirected by dnsspoof, captures password logins
and optionally allows hijacking interactive sessions.
webmitm
proxies and sniffs HTTP/HTTPS traffic redirected by dnsspoof, capturing SSLencrypted logins and form submissions.
Penetration Testing
Dsniffs author refers to it as "a collection of tools for network auditing and penetration testing", and it is
from this perspective that Ill demonstrate putting it to use.
Penetration testing is a form of security auditing, where you attempt to break in to a network - with the
consent of those in charge of the network trying to find weaknesses and vulnerabilities you were not
aware of before, which hopefully leads to fixing those security holes. In my tests with dsniff, I used my
own private home LAN. Unfortunately I do not have a switch at my disposal, so some of the switchdefeating mechanisms were not tested. However, I have seen some of these techniques used
successfully for other purposes (such as clustering) and I have no doubt they work unless extraordinary
precautions and limitations are enforced in the design of the network architecture.
WARNING: If you plan on testing dsniff on a network you do not own, be sure you have written
permission from appropriate authorities, as password and message capture are extremely sensitive
topics and probably illegal without precise guidelines.
In the following sections, we will see how dsniff can be used in several different attack scenarios. It is
worth noting that although most of the techniques used by dsniff are not new, the fact that they are
contained in a single easy-to-use package increases concern since it brings previously complex and
difficult attack scenarios within the capability of the average script kid.
Attack Preliminaries: Accessing the Target Network Traffic
Before dsniff can be used on a LAN, naturally you first need root or administrator access to a host
connected to the LAN. The dsniff toolkit is known to run on Linux, OpenBSD, FreeBSD, and Solaris. It is
likely to be possible to port it to other UNIX platforms as well. There is even a version of dsniff for
Windows NT, although it is older and lacks some of the features in version 2.3.
Once dsniff is compiled and ready on the attacking host within the LAN, there are three different
possibilities for accessing the network traffic:
1. The LAN uses a hub: In this case, nothing extra needs to be done, all network traffic going to any host
on the LAN is visible to all other hosts on the LAN.
2. The LAN uses a switch: In the switched architecture, all hosts are connected to the switch on their own
isolated port, and the switch keeps track of which host is on which port, and then only sends traffic
intended for that host to its port. However, this is mainly intended to increase performance (since each
host gets a dedicated connection instead of being shared like with a hub), and the security benefit is
mostly a side effect. Therefore, it is easy to defeat by simply confusing the switch so it cannot be sure
which host is on which port. Most switches respond to this condition by "failing-open", which means it
begins to act like a hub and send all traffic to all ports. This will also cause network performance to suffer
greatly, which might be noticed by others on the network. To accomplish this:
Use macof to flood the network with random MAC addresses, which will overflow the internal
translation table of the switch. Without an accurate translation table, the switch can no longer
know which host is on which port, which leaves the switch with no choice but to forward all
packets to all ports (like a hub would do). This is known as "fail-open". If the switch does not failopen, the only other option is to "fail-closed" in which case no network traffic will get through to
any host on the LAN at all. Although this latter case is not an option for most equipment, it would
be an especially easy denial-of-service attack.
Note: Most switches can be configured to allow only one, fixed, MAC address per port In that case,
macof would have no effect, but it is a difficult arrangement to manage.
3. The LAN uses a switch and you wish to target a specific host: If you do not want to sniff all the traffic
on the LAN but only wish to target a specific host on it, you can leave the switch alone and just confuse
that specific host into thinking you are the gateway/router. Therefore any traffic that host wishes to send
to outside the LAN will go to your host first. This is the most clandestine form of sniffing, since it only
affects the target host, and only in the way you specify, therefore it is not likely to be noticed by others. To
implement this:
Since we are targeting a particular host and not the entire LAN, we only need to cause the target
host to misdirect its network packets to our MITM attack host (on the LAN). To accomplish this,
we use arpspoof to send fake ARP packets to the target host, telling it that the MITM attack host
is the gateway. That way, any traffic it tries to send outside the LAN will actually go to the MITM
attack host. Before doing this, we have to tell the attack host to forward packets on to the real
gateway otherwise it will be noticed quickly that the target host can no longer communicate
outside the LAN.
Attack One: Password Sniffing
Once the network traffic from the target host, or the entire LAN, has been made available to the sniffing
host using the techniques above, it is a simple matter to start the dsniff program, which will then
automatically detect and capture interesting information from the traffic. In fact, even a normal sniffer will
capture the traffic just as well, but normal sniffers do not have the built-in knowledge of various
application protocols that dsniff has.
Attack Two: Message and File Capture
Using msgsnarf and filesnarf, capturing email messages and files transferred via NFS are just as easy as
capturing passwords. Both these programs do the work of interpreting the relevant network traffic to get
results. msgsnarf saves the captured email in an mbox-format file for standard UNIX mail-readers to use.
filesnarf saves the captured files in the directory it is run from.
Attack Three: URL capture
urlsnarf is similar to the other tools mentioned so far, but specifically written to capture HTTP requests
and log the URL being referenced. webspy is along the same lines, but instead of logging the URL, it
actually commands your local Netscape web browser to follow the URLs as they are sniffed, allowing you
to surf along with the target in real-time. As the README says, this is "a fun party trick."
Attack Four: Man-in-the-Middle
All the previous attacks are considered to be passive since they do not involve altering the behaviour of
the systems being targeted (causing the switch to fail-open can be seen as an active attack on the
switch, but the network traffic is merely observed, not intercepted or modified en route). On the other
hand, a Man-in-the-Middle attack is an active attack since the attacking host plays an important role
managing the network traffic between the source and destination targets.
A MITM attack is when the target host is fooled into thinking it is connecting to a desired destination host
when in fact it is connecting to the attacker host, which then handles the connection to the desired
destination host and proxies traffic between the two from that point on. In this way, the attacker host now
completely controls the connection and can view and/or modify information passing between the
connection it has forged with the source and destination hosts.
This type of attack is particularly effective when dealing with connections encrypted with public-key
cryptography. If you are not familiar with this subject, one good overview is at the Netscape developer
site. Public-key cryptography is an extremely effective encryption concept, but it does require that
connecting host have a copy of the public key from the host being connected to. If the connecting host
does not already have the public key from a previous connection with that host then it will have to get it
from somewhere with protocols such as SSH, the destination host will supply its public key itself. MITM
attacks take advantage of this by intercepting the initial connection attempt and substituting their own
"forged" public key (which they have the private key for and can therefore decrypt the data). If the user at
the connecting end has never seen the correct public key before, it is likely the forgery will not be noticed
and the attack will be a success. Even in the case where the user does have the correct public key to
compare with it, often it just results in a small warning being printed saying the key has changed and if
they want to continue connecting. Most users will simply click OK without another thought. This is not the
fault of the protocol. This is a problem with user education and also with implementations that print simple
warnings when an event as serious as a key change occurs.
Setting up the Attack
Executing the MITM attack is more complex than the others, but dsniffs tools make it almost as easy. In
this scenario there are three systems (plus the gateway) involved in our sample network:
Client Host: Windows, with PuTTY installed (a free Windows SSH program)
IP=192.168.1.77 (MAC address irrelevant)
MITM Attacker: (running dsniff)
MAC=08-00-BA-DD-FE-ED, IP=192.168.1.210
Destination: MAC address irrelevant, IP is outside 192.168.1.x
Hostname = "external.host.com"
Gateway (and DNS server): Serves 192.168.1.x LAN
MAC=08-00-DE-AD-BE-EF, IP=192.168.1.1
1. We have to fool the client (target) host into thinking the MITM host is the gateway. This is done using
arpspoof. At the start, you can see the client has the correct ARP entry for the gateway:
[Client] C:\WINDOWS>arp -a
Interface: 192.168.1.77 on Interface 0x2000003
Internet Address Physical Address Type
192.168.1.1 08-00-de-ad-be-ef dynamic
Running arpspoof on the MITM host will change that. We must remember to enable ip-forwarding so the
MITM host will hand off the packets to the real gateway. To minimize the visibility of this attack, we will
specifically target the client system:
[MITM Host] % Arpspoof t 192.168.1.77 192.168.1.1
Now we can check the clients ARP table again to see if it worked:
[Client] C:\WINDOWS>arp -a
Interface: 192.168.1.77 on Interface 0x2000003
Internet Address Physical Address Type
192.168.1.1 08-00-ba-dd-fe-ed dynamic
You can see that this is the MAC address of the MITM host and all traffic destined for the gateway from
the client will go to the MITM host instead. This phase of the attack is complete.
Next we need to look for DNS queries in the traffic, and when we find one for a destination host we want
to impersonate, we respond to it ourselves instead of passing it on to the real DNS server. We reply with
the IP address of the MITM attack host instead of the real IP. We use dnsspoof to respond to any request
for hostname "external.host.com", which has an IP-address outside the 192.168.1.x network. We can be
very specific by creating an /etc/hosts-format file specifying which hostnames to fake, but by default
dnsspoof will just fake ALL hostname lookups which is fine for our example:
[MITM Host] % dnsspoof
Now to check that it is working on the client:
[Client] C:\WINDOWS>ping external.host.com
Pinging external.host.com [192.168.1.210] with 32 bytes of
data:
It is working, external.host.com is reported to have the IP of the MITM host.
The Target host will then begin the connection to the hostname the user specified, but to the IP address
WE specified (192.168.1.210), which means the MITM host. If the application being used is SSH or a
web browser using HTTPS, we can use sshmitm or webmitm to handle both those protocols (incidentally,
sshmitm only supports the SSH1 protocol, not the newer SSH2 protocol, although it is still subject to the
same trust requirement for the key exchange just as any public-key encryption is). sshmitm or webmitm
sends a forged public-key to the target host, and then also begins a connection of its own to the real
destination server. Once this is done, we actually have two connetions; one going from the target/victim
host MITM host, and another going from the MITM host real destination host. At this point the MITM
host can proxy the traffic between the two hosts, decrypting and re-encrypting all traffic in the process, all
the while monitoring the decrypted traffic. Additionally, since they are two independent connections, we
can always terminate the target hosts connection and simply take over the interactive session from the
MITM destination host ourselves.
To verify this is working, we try connecting to example.host.com using PuTTY on the client host. This is a
host weve connected to before, so we already have a copy of the real public key. What we get is a
warning message:
WARNING POTENTIAL SECURITY BREACH!
The servers host key does not match the one PuTTY has stored in the registry
Then the user has three options: Yes, No, and Cancel. Yes and No both continue the connection (Yes
updates the stored key, No does not), and only Cancel stops the connection. Yes is the default choice if
the user just hits enter without reading or thinking.
At least PuTTY is good about warning the user in clear terms. Some other clients such as SecureCRT (a
commercial client) do not explain what the implications of the warning are at all and simply ask the user if
they wish to continue connecting (defaulting to yes). UNIX SSH clients can be configured for "strict" host
key checking which will automatically disallow any connecting to a host whos host key has changed.
This forces the user to manually remove the existing known-host key if they are sure there is no security
problem.
HTTPS traffic can be attacked in a similar way, using webmitm instead of sshmitm.
Summary
It is hard to study dsniff without being at least slightly troubled by the ease at which you can gather
passwords, emails, files, and eavesdrop on encrypted connections, even on switched networks. This
paper has demonstrated some of these cases and hopefully provides some of the perspective on these
problems that real penetration testing provides. Of course, these vulnerabilities are not the fault of dsniff
or its author and if dsniff causes a greater concern for the basic security of network architectures,
application protocol design, and public-key infrastructure then it will have done a service for us all.
References:
Drury, Jason. "Sniffers: What they are and How to Protect From Them." 11 November 2000.
http://www.sans.org/infosecFAQ/switchednet/sniffers.htm
Song, Dug. "dsniff."
http://www.monkey.org/~dugsong/dsniff/
Seifreid, Kurt. "The End of SSH and SSL? Follow-up." 22 December 2000.
http://www.securityportal.com/seifried/sslssh-followup20001222.html
Song, Dug. "dsniff Frequently Asked Questions."
http://www.monkey.org/~dugsong/dsniff/faq.html
Saso. "Re: Cisco Catalyst switches." 13 June 2000.
http://archives.neohapsis.com/archives/vuln-dev/2000-q2/0916.html
Netscape Communications, Inc. "Introduction to Public-Key Cryptography."
http://developer.netscape.com/docs/manuals/security/pkin/contents.htm
Tatham, Simon. "PuTTY: A Free Win32 Telnet/SSH Client."
http://www.chiark.greenend.org.uk/~sgtatham/putty/
