-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-= -= 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 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-