-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=

                           -= DSniff: Use and Abuse =-

                                  -= By Oshu =-
                           -= unixsecured@yahoo.com =-
                           
                           -= http://www.2600slc.org =-
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

 Words from the Past

Arpa Network Working Group                            Bob Metcalfe (PARC-MAXC)
Request for Comments: 602                             Dec 1973

           "The Stockings Were Hung by the Chimney with Care"

The ARPA Computer Network is susceptible to security violations for at least
the three following reasons:

(1)  Individual sites, used to physical limitations on machine access, have
     not yet taken sufficient precautions toward securing their systems
     against unauthorized remote use.  For example, many people still use
     passwords which are easy to guess:  their fist names, their initials,
     their host name spelled backwards, a string of characters which are
     easy to type in sequence (e.g. ZXCVBNM).

(2)  The TIP allows access to the ARPANET to a much wider audience than
     is thought or intended.  TIP phone numbers are posted, like those
     scribbled hastily on the walls of phone booths and men's rooms.  The
     TIP required no user identification before giving service.  Thus,
     many people, including those who used to spend their time ripping off
     Ma Bell, get access to our stockings in a most anonymous way.

(3)  There is lingering affection for the challenge of breaking
     someone's system.  This affection lingers despite the fact that
     everyone knows that it's easy to break systems, even easier to
     crash them.

All of this would be quite humorous and cause for raucous eye
winking and elbow nudging, if it weren't for the fact that in
recent weeks at least two major serving hosts were crashed
under suspicious circumstances by people who knew what they
were risking; on yet a third system, the system wheel password
was compromised -- by two high school students in Los Angeles
no less.

We suspect that the number of dangerous security violations is
larger than any of us know is growing.  You are advised
not to sit "in hope that Saint Nicholas would soon be there".


 dsniff Abstract

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.


 What platforms are supported?

Officially tested platforms:  OpenBSD (i386), Redhat Linux (i386), and Solaris (sparc). 
Unofficial success reported:  FreeBSD, Debian Linux, Slackware Linux, AIX, and HP-UX.


 How do I sniff in a switched environment?

The easiest route is simply to impersonate the local gateway, stealing client traffic 
enroute 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.


 How to 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.


 How to detect dsniff on a 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...


 How to protect a 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.

'To spoof or not to spoof, that is the packet' 
First, let's look at how normal traffic works. Here is an illustration: 
1.Node A transmits a frame to Node C. 
2.The switch will examine this frame and determine what the intended host is. It will then 
set up a connection between Node A and Node C so that they have a 'private' connection. 
3.Node C will receive the frame and will examine the address. After determining that it is 
the intended host, it will process the frame further. 

Please note that the hosts still perform the examination of the destination address even 
though the switch 'guarantees' that they are the intended host...In general, when Node A 
wants to communicate with Node C on the network, it sends an ARP request. Node C will send 
an ARP reply which will include the MAC address. Even in a switched environment, this 
initial ARP request is sent in a broadcast manner. It is possible for Node B to craft and 
send an unsolicited, fake ARP reply to Node A. This fake ARP reply will specify that Node 
B has the MAC address of Node C. Node A will unwittingly send the traffic to Node B since 
it professes to have the intended MAC address. (Sipes Why your switched network isn't 
secure). This technique of Node B intercepting the frames destined for Node C is called, 
"arp spoofing"; hence, the name of the utility that is being used from the dsniff package,
"arpspoof". For more detailed information on arp spoofing read Stepen Whalen's paper Intro 
to Arp Spoofing. What's being done, using Sipes's example above and in this paper, is that 
the monitoring server is intercepting all traffic on ON-2 and then sending it to Trent. 
Therefore, we are able to get an accurate analysis of what is going on with our network. 


 Defenses
 
You should know how to defend against possible malicious use of dsniff and related programs 
than have to read this paper and wait to the end. The above example, only works for 
networks that are sharing a given gateway. If multiple networks are sharing the same 
gateway and proper filtering rules were in place then this would only work on the network 
where Eve is located. Also, hard-coding the mac address of the gateway on the switch would 
help prevent arp spoofing. That is a temporary fix because a "mac flood" attack can be 
performed on the switch. A "mac flood" is when a bunch of bogus mac addresses fills up the 
memory of the switch and could possibly cause it to "fail-open" (yes dsniff has that 
utility as well called, "macof"). This is essentially the state of a non-switched netowrk 
where packets are broadcasted to every machine on the network until it finds the intended 
host. In this state, and on a non-switched network, users only need to put their interface 
in promiscuous node to sniff traffic. Also, the tedious task of hard-coding the mac 
addresses of the network card on each machine can be done. For example, on linux machines, 
adding the mac address for each machine in the "/etc/ethers" file will prevent arp request 
and replies from being sent and received. A utility named "arpwatch" can be used to email 
the administrator if mac address mismatches are detected on the network. 

The utilities used with dsniff can be used to intercept passwords, email, instant message 
conversations, and other potentially critical information. These tools should be used with 
the utmost care and only authorized users should have access to the server that is doing 
the monitoring. This is the time to pull out that dusty security book and implement strict 
access controls and read up more on security. 
And away we spoof!!! 
First, enable IP Forwarding!! By default IP Forwarding is disabled on Linux. Before this 
can start forwarding traffic to Trent, IP Forwarding must be enabled on the computer 
running arpspoof, hereby called Eve. This is done with the command: 

echo 1 > /proc/sys/net/ipv4/ip_forward 

However, this is enabled in a file named /etc/sysctl.conf: 

net.ipv4.ip_forward = 1 

so IP Forwarding will always be enabled if the network interfaces are reset on Eve or if 
the machine is restarted. (NOTE: If IP Forwarding is not enabled and arpspoof is running 
the network will come to a stand still. Be sure you have IP Forwarding enabled!!!) 
"Arpspoof" at the core of the monitoring can be run by using the following command: 

/usr/sbin/arspoof 192.168.0.1 2>/dev/null 1>/dev/null & 

"2>/dev/null 1>/dev/null" is used to keep the output from being redirected to the console 
(It is sent into nothingness, a little Eastern Philosophy humor). "&" is used to put the 
process in the background. That is really all there is to it to take over a network, see 
why it has the negative publicity. All traffic intended to go to Trent will first be 
redirected to Eve and then to Trent. 

Two other utilities that come with dsniff of use can be effective for bandwidth control, 
"tcpkill" and "tcpnice". There are other bandwidth control programs out there. 
Tomasz Chmielewski Bandwidth-Limiting-HOWTO would probably work just as well. There are 
other utilities with dsniff but they don't have any immediate use for this paper. They can 
either be deleted or made non-executable: 

/bin/chmod 000 /usr/sbin/urlsnarf (Just repeat for each unwanted binary) 

Tcpkill can be used to kill connections to or from a particular host, network, port, or 
combination of all. These programs take standard bpf (Berkeley Packet Filters) filters so 
read the tcpdump man pages for examples on how to create those filters. Also, there are 
other sites on the Internet that have example filters. For example, to prevent any 
connections to the host www.playboy.com use this command command: 

/usr/sbin/tcpkill -9 host www.playboy.com 

The computer that is attempting to go to that site will be blocked from that site only, 
but can surf any other site. It is a good idea to either redirect the output into 
nothingness ( > 2>/dev/null 1>/dev/null) or into a file for later analysis 
(> file.tcpkill ). By default, it will redirect output to the console. More hosts can be 
specified with the command: 

/usr/sbin/tcpkill -9 host www.playboy.com and host www.real.com 

or 

/usr/sbin/tcpkill -9 host www.playboy.com or \( www.real.com or www.penthouse.com \) 

to block well-known ports eg., napster (port 8888 and port 6699) or gnutella (port 6346), 
the command: 

/usr/sbin/tcpkill -9 port 8888 and port 6699 

or 

/usr/sbin/tcpkill -9 port 6346 
will do the trick. 
"Tcpnice" is similar except that it only slows down the connection. The range is 1 through 
20. 20 being the slowest. For example, to slow down napster and gnutella traffic to a crawl 
this command with do that: 

/usr/sbin/tcpnice -n 20 port 8888 and port 6699 

or 

usr/sbin/tcpnice -n 20 port 6346 

If a particular subnet (192.168.1.0/24) was using up a lot of bandwidth this command will 
slow down that subnet: 

/usr/sbin/tcpnice -n 20 net 192.168.1 

This command is a bit drastic because there connection will be crawling. 
The default is "-n 10". 

Substituting the tcpkill command can be used to block that entire subnet for a while: 

/usr/sbin/tcpkill -9 net 192.168.1 

These examples should get you started. 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-
 2600SLC.ORG 2002
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-