 | Level: Introductory Larry Loeb (larryloeb@prodigy.net), Author
01 Jan 2001 Sniffer programs are a data interception technology that increase the risk of so-called "man-in-the-middle" attacks, and with the recent release of dsniff 2.3, security specialists need to be more aware of it than ever. In this installment, part 1 of a two-parter, Larry Loeb takes a look at what makes this network probing tool tick, and how to recognize if you're being "sniffed."
In the conclusion of my article on digital signature technology here on developerWorks, the reader was cautioned that signatures were at risk of so-called "man-in-the-middle" (MITM) attacks. It seems that this intercepting method has caught the fancy of the hackerati of late, especially with the recent release of dsniff 2.3 by researcher Dug Song. This version includes modules than can initiate an MITM attack within a DNS range. As Dug puts it, "sshmitm and webmitm implement active monkey-in-the-middle attacks against redirected SSH and HTTPS sessions by exploiting weak bindings in ad-hoc PKI." It would therefore seem that an increasing number of common security measures are going to be at risk of this form of attack in the near future. Security personnel owe it to themselves to be aware of this sophisticated network probing tool, how it functions, how it can be recognized, and how to deal with any network vulnerabilities that its use might reveal. Sniffer programs
Sniffers are a class of program that listen to and present network traffic in a recognizable form. Commercial ones like Microsoft's Network Monitor as well as public domain tools like Etherman and Curry Sniffer serve the same purpose. They can be used by network administrators for maintenance or network troubleshooting, traffic analysis, and other functions. A sniffer's main operational characteristic is its passivity or non-intrusiveness. Users don't know it's there and capturing data, unlike a network discovery tool like ICMP.
dsniff 2.3
dsniff is a collection of UNIX-executable tools designed to perform network auditing, as well as network penetration. It's been tested by the author under OpenBSD, Red Hat Linux, and Solaris. An older version has been ported to Windows (see Resources), and a version for the Mach/BSD-based Mac OS X can't be too far behind. dsniff was first released by Dug in December 1999 and evidently arose from his work at the Center for Information Technology Integration (CITI), a research lab at the University of Michigan. dsniff has dependencies on some third-party packages, including Berkeley DB, OpenSSL, libnet, and libnids (see Resources). The first two come with the OpenBSD distribution. Each of the tools included in the dsniff distribution has some unique function but falls into a functionality group. In general, the tools dsniff, filesnarf, mailsnarf, msgsnarf, urlsnarf, and webspy are used to passively monitor a vulnerable shared network (such as a LAN where the sniffer sits behind any exterior firewall), looking for content of interest to the attacker. These modules could, for example, be used to try to obtain a password that has been sent in the clear or is weakly encrypted. The tools can auto detect various messaging protocols (about 30 are included) when dsniff is launched with the "-m" option. Urlsnarf intercepts all http requests from the affected net and formats them into the Common Log Format (CLF) used by MS IIS and Apache. This means a log analysis program that a webmaster might already have can be used to interpret the results of urlsnarf. Urlsnarf is hard-coded to listen on ports 80 (where clear text http resides) as well as port 3128 (MS-proxy) and 8080 (generic proxy). It's sort of overkill, just monitoring to see if people are going to porn sites on company time -- but it would work.
Spoofers and layer 2 switching
arpspoof, dnsspoof, and macof work on the interception of "switched" network traffic that is usually unavailable to a sniffer program because of the segment switching that occurs at the ISO layer 2 level. (ISO layer 2 means the datalink level of a network, like Ethernet.) Thanks to dsniff, the knee-jerk IT response of upgrading to a switched network from a vulnerable shared non-switched Ethernet will not be as prevalent as it has been in the past. The rationale for this kind of change is that because a switching network moves data packets from one destination to another without passing them through any of the other nodes of a network, the switched topology would reduce the chances of interception. It seems the modules just go upstream to the destination -- and attack from there. This implies that the attacker can access some place on the network common to the target and attacker. In practice, this means that the dsniff software can only arpspoof a machine that is on the same subnet as the attacking computer. The dsniff tools in their current incarnation can't "jump" subnets to attack where their host is not already 'Net-connected. It is possible, of course, to remotely set up a zombie user to run dsniff and send the results out, but at that point you've already taken pains around rlogin privileges, right? If not, you've got bigger things to worry about than sniffers. To get around the level 2 packet switching, dsniff "spoofs" the network into thinking that it is a gateway that data must pass through to get outside. Arpspoof (previously called arpredirect) is the tool that actually does this. Arpspoofing uses ARP (address resolution protocol) as the wedge for opening up the victim. First, the attacker uses the arpspoof tool to send out a forged ARP packet to the target system. This forged packet tells the target that the default gateway has been changed to the address given by the attacker, which is usually the attacker's own IP address. This is the point where the previously-mentioned subnet considerations emerge. To send and get the forged packet to work, the attacker must be on the same subnet. This implies that the attacker and the target usually share a common default gateway, one known to the attacker. Once the changes in the ARP tables are accepted by the target, every time the target sends traffic to the outside, it sends the traffic to the attacker masquerading as the gateway. The attacker forwards the packet on to its original destination, but retains the information contained. This way, the gateway forwards the packet to the correct ultimate destination, and the compromised user has no idea something is going on. /proc/sys/net/ipv4/ip _forward )sysctl -w net.inet.ip.forwarding=1. |
If forwarding is not done, the attacking machine will wipe the LAN's connectivity by becoming a packet sink. Should one of these sinks develop on a local network, the operator should look to see if an attack has been mounted, albeit ineptly. Once the IP forwarding is established, the attacker can read anything sent out by the target in clear text -- like Web pages or e-mail, for instance.
One spoofing remedy
This suggests one remedy for this kind of spoofing: Encrypt the content. If something is encrypted with public/private key cryptography before hitting the network, the key does not traffic over the 'Net and can't be sniffed by the attacker. An alternate detection remedy is a tool like arpwatch. This makes a noise when the ARP mappings are updated, but the operator still has to make a decision as to whether or not the tables are being updated in normal 'Net operations. Enforcing static ARP entries for certain hosts may also be a countermeasure.
The SSL conundrum
Some gentle readers may be scratching their heads wondering why we just don't use SSL (Secure Sockets Layer) for session-level operation or SSH (Secure Host) and encrypt all traffic. SSL is already implemented in Web browsers. The reason why we can't be assured that these protocols are secure is due to what's been added to dsniff's arsenal -- "sshmithm" and "webmithm." These tools can conduct an MITM attack directed against SSH hosts (sshmithm) and Web clients (webmitm). The tools can do this because of what Dug aptly called the "weak bindings in ad-hoc PKI." These lead to redirected SSH and HTTPS sessions by the attacker using a self-signed certificate (generated by the OpenSSL code), which fools the target into thinking that where it wants to go has just been moved slightly in cyberspace. These redirected sessions eventually get connected to the true destination, but the destination may think the MITM is the correct originator, and send return packets back to the masquerading MITM. Right now, there are few ways to verify and authenticate the exchanged certificates used when SSL or SSH first encounters a site or server and is most vulnerable to the MITM style attack. This is the PKI (Public Key Infrastructure) problem in a nutshell. While proposals like IPSEC have arisen, it is an unwieldy and mostly unimplemented proposal. Another proposal is DNSSEC, a set of extensions to DNS (Domain Naming Service) for securing the Internet naming system. The idea is to create verifiable bindings between host names and keys. However, no such systems are yet commonly deployed, so current SSH implementations mostly take the easiest way out: a local database of key/host name associations. This is maintained by the sysadmin or individual users -- which leads to the problem of trusting the database when you don't know the admin. So, we currently live with the ad hoc bindings that MITM attacks use as a springboard.
Some obvious warnings of attack
Of course, other methods exist to detect and derail dsniff or other sniffers. However, these methods require that you pay attention to the nit and grit of a network. For example, when SSH is being spoofed to change a gateway address, the SSH client gets noisy with an alert informing of the change. It looks like this: "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ |
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now
(man-in-the-middle attack)! It is also possible that
the host-key has just been changed. Please contact
your system administrator." |
Now, if a user ignores this and proceeds onward, your security policies need revision. This is the kind of alert that should ring the sysadmin's pager immediately.
Welcome to the jungle!
MITM attacks have been taken to a new and more intrusive level with dsniff 2.3. dsniff opens a network's vulnerabilities for local or remote inspection, but in a way that allows countermeasures to be taken. If anything, the program should increase the sysadmin's awareness of how the network can be compromised before it can actually happen. In part 2 of this series, we'll take a look at what can be done to reduce a network's exposure to sniffers and other attacks.
Resources - You can find an earlier version of dsniff, which has been ported to Windows, at http://www.datanerds.net/~mike/dsniff.html.
- You can find Dug Song's release of dsniff 2.3 at monkey.org.
-
Sleepycat Software is the maker of the Berkeley Database, an open-source, embedded database system that provides built-in database support for desktop and server applications and for information appliances.
-
The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured, and open source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library.
-
Libnet is a collection of routines that helps with the construction and handling of network packets. Libnids is an implementation of an e-component of the Network Intrusion Detection System that emulates the IP stack of Linux 2.0.x.
About the author | | |
Larry Loeb has been writing and consulting since the 20th century about
computer topics. He has published a book on SET, the protocol developed
by Visa and Mastercard for secure electronic transactions. He can usually
be contacted at larryloeb@prodigy.net should there be any questions, bribes,
or offers of a questionable nature.
|
Rate this page
| |
