As we shift from a defensive viewpoint to an offensive one, we start to use more aggressive tools. These are more likely to cause damage or intercept information we shouldn't have access to, and for this reason awareness of the legalities and risks of "hacking" is important. When experimenting with any tools in this section, it is strongly advised that you utilize the isolated lab.

The packet sniffing we've looked at using Ethereal is considered passive sniffing. Setting the network card to promiscuous mode does not necessarily elicit a response, but cannot be detected. This is obviously safer, but terribly ineffective on a switched network. To intercept traffic in these situations, we must convince the sender and/or switch to transmit packets to us. This often makes us traceable though, so this is called active sniffing.

ARP poisoning means to corrupt an ARP cache with false entries which we do by sending bogus replies to ARP queries. Then, when the requester actually tries to send data, they route it to our destination. A similar method of deception is DNS spoofing, which sends bogus replies to DNS queries. This can be harder to pull off however since it would also generally require ARP poisoning as well. We'll use this later in our man-in-the-middle attack.

The Dsniff toolkit created by Dug Song[1] is a collection of slightly dated but often very effective tools for penetration testing. Included are ARP and DNS spoofers (arpspoof and dnsspoof), man-in-the-middle attacks --webmitm and sshmitm --for both HTTPS and ssh (only version 1 of ssh is supported, since as Dug states in the man page, "this program is far too evil already"), an assortment of traffic disrupting/modifying tools, and several others.

One more that applies to active sniffing is macof, which attempts to flood a switch with thousands of MAC addresses as quickly as possible. In old or cheap switches, if the device's memory is quickly exhausted, the switch may start allowing traffic through all ports rather than failing entirely[2]. Clearly this serves the same purpose as our spoofing (at least when it works). This is one of the tools that is unlikely to work anymore, but is worth trying against older hardware.

Man-in-the-middle attacks (or "monkey-in-the-middle", as they're referred to in the Dsniff documentation) are very similar to proxies. A proxy server works as a waypoint between a client and the outside world (usually for a specific service). By acting as a liaison for the client, it can filter both incoming and outgoing data for anything harmful, as well as provide some additional privacy (the outside source communicates solely with the proxy, meaning they won't have access to the actual client). A man-in-the-middle attack serves the same purpose, only without the client's knowledge. Because the client is passing all its information including credentials like usernames, passwords, bank account numbers, etc. directly to the proxy, the proxy is free to read and modify it. Even encrypted transmissions can be circumvented (as we will see in a moment).

We will now demonstrate a man-in-the-middle attack using webmitm and dnsspoof. For this example Alice is trying to connect to the cs.marlboro.edu server while Eve attempts to steal her password. To simplify this slightly, we assume Eve is the gateway for Alice (this could be spoofed, but if Alice is on our isolated wired lab network, Eve might be acting as a bridge since she has a wireless card as well).

When Eve runs webmitm for the first time, it generates a bogus SSL certificate based on user input (note she's running as root here):

She now uses dnsspoof to reroute traffic to her. Dnsspoof takes a hosts file to reply to specific requests or replies to all by default. Eve only wants traffic bound for cs.marlboro.edu, so she creates a hosts file with two entries looking like this:

and runs dnsspoof with these options:

(The -i option specifies an interface.) The above IP address is that of the computer she's running webmitm on. This could be different than the one running dnsspoof. The second hosts line is particularly wicked. cs.marlboro.edu has a genuine certificate that authenticates properly. On campus however, it's common habit to just enter "cs" in our browser's address bar, which gets correctly resolved. Because the names are technically different, our browser presents us with an error message when we try to log in this way. Webmitm also produces an error message, since the certificate is not authorized by a recognized source, but the average user familiar with this behavior probably won't pause to read it.

So now when Alic asks for the IP address corresponding to cs, she gets Eve's address. When she connects, she's receiving her page from cs, but through Eve. And when Alice thinks she's negotiating encryption keys with cs, she's in fact negotiating with Eve, who in turn is swapping different keys with cs.

This once again emphasizes that the weakest link in security is almost always human error. Consider the following message:

How many times have you immediately typed "yes" to this prompt? Bob is lucky that Eve doesn't have an sshmitm program that supports version 2 ssh (or does she?) because he would have just handed her his password without a second thought.

1) http://www.monkey.org/~dugsong/dsniff/
2) Harris, Shon et all, Gray Hat Hacking: The Ethical Hacker's Handbook, McGraw-Hill/Osborne, 2005

http://cs.marlboro.edu/ courses/ fall2006/networking/ private/ tableofcontents/ AttackConcepts
last modified Monday April 2 2007 2:44 pm EDT