Copy Link
Add to Bookmark
Report
DSniff: Use and Abuse
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=
-= 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
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
