The next type of attack to examine is session hijacking. Another "nonattack," session hijacking is a means of either gaining total or partial control over an established TCP/IP connection. Session attacks rely on a trusted connection between two computers to be in place, and then work to either modify packets traveling between the machines or take the place of one of the two computers.
Session hijacking is an effective means of gaining control over a machine or process that otherwise would not be accessible. Most authentication (such as AFP, Kerberos, and so on) take place during the initiation of a connection. After authentication, the conversation is considered trusted . This is the point at which attackers want session hijacking to take place.
The most common and effective form of session hijacking is called man-in-the-middle and works by placing a computer in the "middle" of an established connection. Both ends of a connection must be "convinced" that to speak to the other side, they need to go through the attacking computer.
To do this, the attacker must be located on the same network as either of the victim computers. As you might guess, spoofing is required to bring all the pieces together. Consider Figure 9.4, which displays a simple network with an established connection in place.
Computer A (10.0.1.100, 00:30:65:12:f2:15) speaks to Computer B (192.168.0.100, 00:30:65:12:f2:25) via the Router (10.0.1.1, 00:30:65:12:f2:01), while Computer C (10.0.1.101, 00:30:65:12:f2:50) sits idle on the same network as A. For all intents and purposes, the session that is being hijacked is between Computer A and the router; the location of B is irrelevant. In the initial established state, Computer A has an ARP table that contains a mapping between the IP 192.168.0.100 and the MAC address 00:30:65:12:f2:01, or, in other words, to communicate with a machine at the IP address of Computer B, Computer A must send packets to the MAC address 00:30:65:12:f2:01 ”the router. Likewise, the router's ARP table maps between the IP address 10.0.1.100 and MAC address 00:30:65:12:f2:15, both belonging to Computer A.
To hijack the session, Computer C implements a spoofing attack in which it purports to be both the remote client (Computer C) and the local victim (Computer A), and advertises this via unrequested ARP replies to Computer A and the router, respectively. The result can be seen in Figure 9.5.
Now, Computer A has an ARP mapping between 00:30:65:12:f2:50 (Computer C) and Computer B, while the router has a mapping between Computer A and 00:30:65:12:f2:50 (Computer C). The result is that Computer A transmits data to what it believes to be the remote Computer B by way of the router, but instead transmits it to Computer C. Computer C can modify the packet (or do anything it likes) and retransmit it to the router, purporting to be Computer A.
Session hijacking, at one time, was very difficult to implement. Today it is a matter of finding the right software and choosing your targets. The software ettercap , for example, can be used to implement a man-in-the-middle attack without its user having any knowledge of networking or spoofing.
Discussed in Chapter 7, you can use ettercap to start a man-in-the-middle attack by choosing a source and destination address, using A to enter ARP sniffing mode ( poisoning the ARP caches of both the source and destination), choosing the connection to hijack, then pressing I to start injecting characters into the packet stream, as shown in Figure 9.6.
Other methods of session hijacking may employ other mechanisms such as DoS attacks against one side of the connection. After bringing down one side, the attacker spoofs the original connection, completely replacing the original.
Protecting against session hijacking is reasonably straightforward. Following these guidelines will greatly reduce your chances of being hijacked:
First and foremost, do not use unencrypted protocols, such as Telnet and FTP. Encrypted communications via IPSec or SSH are not easily forged, although full SSH1 sniffing is implemented in ettercap . SSH2 is preferable because it is much more secure.
If possible, use static ARP mappings for your critical systems ( arp -s mygateway.mynetwork.net 10.0.1.1 ).
Use software such as ettercap or arpwatch to detect clients that may be involved in a spoofing attack.
The arpwatch software is a simple-to-use solution you can use to detect spoofing without needing to manually monitor your network. Arpwatch maintains a database of host/ethernet mappings and automatically logs changes to syslogd and email.
For a network with static IP addresses (or static DHCP mappings), the only changes that should be detected are when a system is added or replaced on the network. Other changes can be interpreted as a potential spoofing attack.
Download arpwatch from http://online.securityfocus.com/tools/142.
Unarchive and enter the source code distribution:
% tar xf arpwatch-2.1a4.tar % cd arpwatch-2.1a4/
Next, configure with ./configure powerpc :
% ./configure powerpc loading cache ./config.cache checking host system type... powerpc-unknown-none checking target system type... powerpc-unknown-none checking build system type... powerpc-unknown-none checking for gcc... (cached) gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no ...
Now you need to make a few changes to the source for it to install and work correctly on Mac OS X. Edit the file addresses.h to define your email address. By default, the WATCHER constant is set to root ; you should replace this with the address to be notified when changes are detected.
Next, open Makefile and change the default SENDMAIL location from
SENDMAIL = /usr/lib/sendmail
SENDMAIL = /usr/sbin/sendmail
For this to work, sendmail must be configured to send email. It does not need to run as a daemon, but you'll need to follow the steps in Chapter 13 for it to be functional.
Finally, perform a search on the string (once again in Makefile ) -o bin -g bin and replace all occurrences with -o root -g admin . You're now ready to compile and install:
# make gcc -O -DDEBUG -DHAVE_FCNTL_H=1 -DHAVE_MEMORY_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_BCOPY=1 -DHAVE_STRERROR=1 -DWORDS_BIGENDIAN=1 -DRETSIGTYPE=void -DRETSIGVAL= -DHAVE_SIGACTION=1 -DDECLWAITSTATUS=int -DSTDC_HEADERS=1 -DARPDIR=\"/usr/local/arpwatch\" -DPATH_SENDMAIL=\"/usr/lib/sendmail\" -I. -c ./db.c # make install /usr/bin/install -c -m 555 -o root -g admin arpwatch /usr/local/sbin /usr/bin/install -c -m 555 -o root -g admin arpsnmp /usr/local/sbin # cp arpwatch.8 /usr/share/man/man8/
After installing, arpwatch can be invoked as root from /usr/local/sbin/arpwatch . It requires the support file arp.dat to be created beforehand to contain the mapping database. You may also need to invoke arpwatch with one of its switches, shown in Table 9.1.
Debugging mode. Arpwatch does not fork and outputs all data to stderr rather than email or syslogd .
The path to the arp mapping file. This file must exist before you start arpwatch .
-i <network interface>
Set the network interface to monitor. The default is en0 .
Read the packet information from a tcpdump file rather than a network interface.
For example, I can start arpwatch on my network interface en1 like this:
# touch /var/db/arp.dat # /usr/local/sbin/arpwatch -f /var/db/arp.dat
After it runs for a few seconds I start to see messages like this in /var/log/system.log and my mailbox:
Jan 20 00:37:59 Computer arpwatch: listening on en1 Jan 20 00:38:03 Computer arpwatch: new station 10.0.1.1 0:90:27:9a:4c:c1 Jan 20 00:38:04 Computer arpwatch: new station 10.0.1.119 0:30:65:4:dc:46 Jan 20 00:38:25 Computer arpwatch: new station 10.0.1.2 0:30:65:2d:c7:d1 Jan 20 00:38:42 Computer arpwatch: new station 10.0.1.250 0:30:65:dc:68:88 Jan 20 00:41:25 Computer arpwatch: new station 10.0.1.101 0:30:65:12:f2:15
During the first several minutes, arpwatch will build the mapping table and generate messages for each machine on the network. After the table is built, however, the only messages logged will be those indicating a change in the network.