-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -=--=-=-= -= DSniff: Use and Abuse =-= By Oshu =-= unixsecured@yahoo.com =-= http://www.2600slc.

org =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -=-=-=-= Words from the Past Arpa Network Working Group Request for Comments: 602 Bob Metcalfe (PARC-MAXC) 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. d sniff, filesnarf, mailsnarf, msgsnarf, urlsnarf, and webspy passively monitor a network for

interesting data (passwords, e-mail, files, etc.). arpspoof, dnsspoof, and maco f facilitate the interception of network traffic normally unavailable to an attack er (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 H P-UX. How do I sniff in a switched environment? The easiest route is simply to impersonate the local gateway, stealing client tr affic 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 accc omplishes the same (fragrouter -B1). Several people have reportedly destroyed connectivity on their LAN to the outsid e world by arpspoof'ing the gateway, and forgetting to enable IP forwarding on the attackin g 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 symmetri c 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 sim ple 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 1.2.3.4 *.passport.com *.hotmail.com

where 1.2.3.4 is the IP address of your attacking machine. Local clients attemp ting to

connect to Hotmail will be sent to your machine instead, where webmitm will pres ent 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 mo st 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 wh o 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 netwo rk, such as those caused by arpspoof or macof. At layer-3: A programmable sniffer such as NFR can look for either the obvious n etwork 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 winni ng 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 t cpnice 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 dete ctor 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 f or 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 i s 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 cl eartext protocols on your network. dsniff is useful in helping to detect such policy vi olations, especially when used in magic (dsniff -m ) automatic protocol detection mode. T his 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 gene rally subject to the kind of trivial monkey-in-the-middle attacks that plague PKI in s uch ad-hoc deployments as SSH and HTTPS. Leveraging an authenticated naming service like D NSSEC for secure key distribution is one solution, although realistically several years of f 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' conn ection. 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 addr ess even though the switch 'guarantees' that they are the intended host...In general, whe n 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 Nod e 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 dsnif f package, "arpspoof". For more detailed information on arp spoofing read Stepen Whalen's p aper Intro to Arp Spoofing. What's being done, using Sipes's example above and in this pape r, 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 relat ed 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 th e network where Eve is located. Also, hard-coding the mac address of the gateway on the sw itch 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 fi lls 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-switche d 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 a rp 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, instan t 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 implem ent 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. Bef ore this can start forwarding traffic to Trent, IP Forwarding must be enabled on the comp uter 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 E

ve 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 comma nd: /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 th e 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 netw ork, see why it has the negative publicity. All traffic intended to go to Trent will firs t 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. Th ere 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, p ort, or combination of all. These programs take standard bpf (Berkeley Packet Filters) f ilters so read the tcpdump man pages for examples on how to create those filters. Also, th ere are other sites on the Internet that have example filters. For example, to prevent a ny 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 sit e only, but can surf any other site. It is a good idea to either redirect the output int o 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 host s 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.co m \) to block well-known ports eg., napster (port 8888 and port 6699) or gnutella (po

rt 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 com mand 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 w hile: /usr/sbin/tcpkill -9 net 192.168.1 These examples should get you started. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-==-= 2600SLC.ORG 2002 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-