1. General
1.1. What is dsniff?
dsniff is a collection of tools for network auditing and penetration testing. dsniff, filesnarf, mailsnarf, msgsnarf, urlsnarf, and webspy passively monitor a network for interesting data (passwords, e-mail, files, etc.). arpspoof, dnsspoof, and macof facilitate the interception of network traffic normally unavailable to an attacker (e.g, due to layer-2 switching). sshmitm and webmitm implement active monkey-in-the-middle attacks against redirected SSH and HTTPS sessions by exploiting weak bindings in ad-hoc PKI.
1.2. Why are you releasing it?
Without strong motivation for change, insecure network protocols and their implementations often go uncorrected, leaving much of the Internet vulnerable to attacks the research community has warned about for years (e.g. intercepting SSH / PGP private keys and .Xauthority files via NFS, sniffing in a switched environment, exploiting trust relationships based on DNS, monkey-in-the-middle attacks against SSH and HTTPS, etc.). At the same time, pending legislation such as UCITA, the European Draft Cybercrime Treaty, and the DMCA threatens to criminalize security research that exposes flaws in the design and implementation of distributed systems. By publishing dsniff while it is still legal to do so, sysadmins, network engineers, and computer security practitioners will be better equipped with the tools to audit their own networks before such knowledge goes underground.
1.3. What platforms are supported?
Only three platforms are available to me for testing: OpenBSD (i386), Redhat Linux (i386), and Solaris (sparc). Others have reported success on FreeBSD, Debian Linux, Slackware Linux, AIX, and HP-UX.
A Windows port of an older version of dsniff is available from http://www.datanerds.net/~mike/dsniff.html, and a MacOS X port is available via MacPorts.
1.4. What else is required?
The dsniff package relies on several additional third-party packages:
OpenBSD has already integrated the first three packages into the base system, leaving only libnet and libnids as additional dependencies (see /usr/ports/net/{libnet,libnids} or the OpenBSD FTP site for binary packages).
Linux, Solaris, and most other OSs require building all third-party packages first (including Redhat, which ships with a non-standard libpcap) (see rpmfind.net for binary RPMs, which you should always check with rpm --checksig).
This software also requires a basic understanding of network security for its proper use. I will not entertain such inane questions as "Can I use this to spy on my wife's chat sessions?", nor will I bother explaining the mechanism behind each exploit. RTFM, and RTFS.
1.5. Is there a mailing list?
A mailing list for dsniff announcements and moderated discussion is available. Send e-mail with the word "subscribe" in the body of the message to dsniff-request@monkey.org. No archive of this list is available yet.
2. Installation
2.1. Where can I find dsniff RPMs for Linux?
See Henri Gomez's (hgomez@slib.fr) RPM distribution site at http://www.falsehope.com/ftp-site/home/gomez/dsniff/ or try rpmfind.net for other third-party RPMs. Debian packages are also available, see http://packages.debian.org/unstable/net/dsniff.html.
2.2. Where can I find dsniff pkgs for Solaris?
See sunfreeware.com for Solaris 8 packages.
2.3. Do I really have to install all those third-party packages?
No. dsniff's configure script will accept a package's build directory as an argument to its various --with-libxxx flags. Build all third-party packages first, before running dsniff's configure script.
2.4. Make dies with missing R_NOOVERWRITE and R_NEXT declarations?
See the next question. I get this most from Linux users, esp. those using Mandrake, for some reason.
2.5. Make dies with undefined symbol dbopen or __db185_open"?
Be sure to build Berkeley DB with ./configure --enable-compat185.
2.6. Configure can't find Berkeley DB, even though it's installed!
dsniff-2.2 had a broken configure script that refused to find any installed Berkeley DB. Point ./configure --with-db at your Berkeley DB build directory instead, or upgrade to dsniff-2.3.
2.7. Make dies with "undefined reference to pcap_open_live_new"?
You're probably linking against a different version of libpcap than the one used to build libnids (this is often reported by Linux users who've installed libnids from an RPM). Be sure to build libnids and dsniff against the same libpcap distribution.
2.8. Make dies with "undefined reference to RAND_status"?
Upgrade your installation of OpenSSL.
3. Operation
3.1. How do I sniff in a switched environment?
The easiest route is simply to impersonate the local gateway, stealing client traffic en route to some remote destination. Of course, the traffic must be forwarded by your attacking machine, either by enabling kernel IP forwarding (sysctl -w net.inet.ip.forwarding=1 on BSD) or with a userland program that acccomplishes the same (fragrouter -B1).
Several people have reportedly destroyed connectivity on their LAN to the outside world by arpspoof'ing the gateway, and forgetting to enable IP forwarding on the attacking machine. Don't do this. You have been warned.
3.2. arpspoof always fails with "couldn't arp for host"?
You can only arpspoof hosts on the same subnet as your attacking machine.
3.3. Why isn't dsniff / *snarf seeing anything?
3.3.1. ...when using arpspoof to intercept client traffic?
Make sure you are actually forwarding the intercepted packets, either via kernel IP forwarding or with fragrouter.
If you are indeed seeing the client's half of the TCP connection (e.g. as verified using tcpdump), make sure you've enable dsniff's half-duplex TCP stream reassembly (dsniff -c). The *snarf tools do not yet support this mode of operation.
3.3.2. ...when I can see ongoing connections with tcpdump?
libnids, dsniff's underlying TCP/IP reassembling library, needs to see the start of a connection in order to follow it. There are several good reasons for this, as outlined in Ptacek and Newsham's seminal paper on network IDS evasion.
The best you can do, in a live penetration testing scenario, is to
- start sniffing
- selectively reset existing connections with tcpkill, and then
- wait for the users to reconnect
This is horribly intrusive and evil, but then again, so are pen tests. :-)
3.3.3. ...when sniffing a busy network, or a switch's monitor port?
You may be losing some packets, either at the switch's monitor port (mirroring ten 100 Mbit Ethernet ports to a single port is never a good idea) or within libpcap - anathema to libnids, which needs to see all packets in a connection for strict reassembly. Try enabling dsniff's best-effort half-duplex TCP stream reassembly (dsniff -c) instead.
Other general performance enhancements for sniffing include:
- SMP, which on most OSs results in only one processor handling the high interrupt load, leaving the other to do real work
- good NICs and drivers with working DMA
- large kernel buffers for efficient packet capture (OpenBSD's BPF already does this)
- custom kernel support for single-copy packet capture (e.g. direct access to such buffers in kmem from userland)
3.3.4. ...when sniffing traffic on an unusual port?
Try enabling dsniff's magic (dsniff -m) automatic protocol detection, which should detect the appropriate protocol (if dsniff knows about it) running on any arbitrary port. If dsniff still fails to pick up the traffic, it may be an unusual protocol dsniff doesn't yet support. Create a dsniff services file like
hex 12345/tcp
where 12345 is the TCP port of the unknown service, run dsniff with -f services and send the resulting hexdump of the connection trace to me. Some proprietary protocols transmogrify almost daily, it's not easy keeping up!
3.3.5. ...when sniffing unknown traffic, or a new version of some protocol?
dsniff's decode routines are admittedly pretty sleazy, and cut many corners for the sake of performance (and simplicity - you try fully decomposing all 30+ open / proprietary protocols that dsniff handles!). Additionally, many of the protocols dsniff handles are completely proprietary, and required a bit of reverse engineering which may not have been all that complete or accurate in the face of new protocol versions or extensions.
The best way to get new protocols handled by dsniff is to send me traffic traces of a few complete connections / sessions, from start to finish (making sure to capture the packets in their entirety with tcpdump -s 4096, or with Ethereal), along with any pointers to relevant documentation (or client/server implementations).
If you'd like to give it a try yourself, add an entry to dsniff's dsniff.services file to map the traffic you wish to analyze to the "hex" decode routine, and dissect the hexdumps manually.
3.4. How do I sniff / hijack HTTPS / SSH connections?
Although HTTPS and SSH are encrypted, they both rely on weakly bound public key certificates to identify servers and to establish security contexts for symmetric encryption. As the vast majority of users fail to comprehend the obtuse digital trust management PKI presents (e.g. is an X.509v3 DN really meaningful to you?), a simple monkey-in-the-middle attack works quite well in practice.
Client traffic to a target server may be intercepted using dnsspoof and relayed to its intended destination using the sshmitm and webmitm proxies (which also happen to grep passwords in transit). For example, to sniff Hotmail webmail passwords, create a dnsspoof hosts file such as:
1.2.3.4 *.passport.com 1.2.3.4 *.hotmail.com
where 1.2.3.4 is the IP address of your attacking machine. Local clients attempting to connect to Hotmail will be sent to your machine instead, where webmitm will present them with a self-signed certificate (with the appropriate X.509v3 distinguished name), and relay their sniffed traffic to the real Hotmail site.
sshmitm is perhaps most effective at conference terminal rooms or webcafes as most travelling SSH users don't carry their server's key fingerprint around with them (only presented by the OpenSSH client, anyhow). Even sophisticated SSH users who insist on one-time passwords (e.g. S/Key), RSA authentication, etc. are still at risk, as sshmitm supports monitoring and hijacking of interactive sessions with its -I flag.
3.5. Why isn't dsniff capturing Oracle logins?
Increase the default snaplen with dsniff -s 4096. Oracle logins can be quite chatty...
3.6. Why does webmitm report "openssl: not found"?
webmitm uses the openssl binary to generate certificates. Make sure the openssl binary (usually in /usr/local/ssl/bin/ on most systems) is in your PATH.
3.7. Why is dsniff crashing with "Bus Error (core dumped)"?
Chances are, you've built against an unstable version of libnids (libnids-1.14 on Solaris in particular). Upgrade to the latest version at http//www.packetfactory.net/Projects/Libnids/, and if you still have problems, rebuild everything with -g and send me a gdb stack backtrace.
3.8. Why do I get "Socket type not supported" on my Cobalt Linux box?
From Brian Costello (http://www.mksecure.com/): You need to compile your kernel to include a Packet Socket - under Networking Options in your linux kernel config, you say YES to Packet Socket. If you have a 2.3/2.4 kernel, you should probably say yes to the mmapped I/O, as it gives superior performance.
From Simon Taylor (simon@band-x.net): It's actually already in the kernel, as a module: /sbin/insmod af_packet.
3.9. My Linux 2.2 - 2.4 box crashes / NIC stops responding when I run your tools!
Consult your local Linux bazaar for advice. ;-)
Perhaps you've built an unstable kernel?
4. Countermeasures
4.1. How do I detect dsniff on my network?
At layer-2: LBL's arpwatch can detect changes in ARP mappings on the local network, such as those caused by arpspoof or macof.
At layer-3: A programmable sniffer such as NFR can look for either the obvious network anomalies or second-order effects of some of dsniff's active attacks, such as:
- ICMP port unreachables to the local DNS server, a result of dnsspoof winning the race in responding to a client's DNS query with forged data
- excessive, or out-of-window TCP RSTs or ACK floods caused by tcpkill and tcpnice
dsniff's passive monitoring tools may be detected with the l0pht's antisniff, if used regularly to baseline network latency (and if you can handle the egregious load it generates). Honeynet techniques for sniffer detection (such as the sniffer detector at IBM Zurich GSAL) also present an interesting countermeasure of last resort...
4.2. How do I protect my network against dsniff?
At layer-2: Enabling port security on a switch or enforcing static arp entries for certain hosts helps protect against arpspoof redirection, although both countermeasures can be extremely inconvenient.
At layer-3: IPSEC paired with secure, authenticated naming services (DNSSEC) can prevent dnsspoof redirection and trivial passive sniffing. Unfortunately, IPSEC's IKE is an overblown key exchange protocol designed by committee, so unwieldy and perverse that widespread deployment across the Internet is almost unthinkable in the immediate future.
At layer-4: Don't allow proprietary, insecure application protocols or legacy cleartext protocols on your network. dsniff is useful in helping to detect such policy violations, especially when used in magic (dsniff -m) automatic protocol detection mode. This is largely a matter of remedial user education perhaps best left to the experienced BOFH. :-)
Strong, trusted third-party network authentication (such as Kerberos) isn't generally subject to the kind of trivial monkey-in-the-middle attacks that plague PKI in such ad-hoc deployments as SSH and HTTPS. Leveraging an authenticated naming service like DNSSEC for secure key distribution is one solution, although realistically several years off from widespread deployment. A reasonable interim measure is to have users enable SSH's StrictHostKeyChecking option, and to distribute server key signatures to mobile clients.
Note: Kerberos has its own problems, though - see kdcspoof, and my AFS/Kerberos patch for John the Ripper.
Firewalls can be a mixed blessing - while they protect sensitive private networks from the untrusted public Internet, they also tend to encourage a "hard on the outside, soft on the inside" perimeter model of network security. dsniff has perhaps been most effective behind the firewall, where Telnet, FTP, POP, and other legacy cleartext protocols run freely, unfettered by corporate security policy.
5. References
5.1. Where can I learn more about these attacks?
Many of the attacks dsniff implements are quite old, although still effective in most environments. Clearly, we still have a long way to go in securing our networks...
- S. Bellovin. "Using the Domain Name System for System Break-Ins". Proceedings of the 5th Usenix UNIX Security Symposium, June 1995.
- M. Blaze. "NFS Tracing by Passive Monitoring". Proceedings of the Winter USENIX Conference, January 1992.
- C. Ellison. "Establishing Identity Without Certification Authorities". Proceedings of the 6th USENIX Security Symposium, July 1996.
- E. Felten, D. Balfanz, D. Dean, D. Wallach. "Web Spoofing: An Internet Con Game". 20th National Information Systems Security Conference, October 1997.
- D. Farmer, W. Venema. "Improving the Security of Your Site by Breaking Into it". December 1993.
- U. Flegel. "The Interaction Between SSH and X11". September 1997.
- T. Ptacek, T. Newsham. "Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection". Secure Networks, Inc., January 1998.