Switch Snif ng in Software

Creating Quick Response Code in Software Switch Snif ng

You just put in your new shiny switch in the hopes of achieving network nirvana with both improved speed and security The prospects of increased speed and the ability to keep those curious users from sniffing sensitive traffic on your corporate network make you smile Your new switch is going to make all your problems disappear, right Think again The Address Resolution Protocol (RFC 826) provides a dynamic mapping of a 32-bit IP address to a 48-bit physical hardware address When a system needs to communicate

7:

with its neighbors on the same network (including the default gateway), it will send out ARP broadcasts looking for the hardware address of the destination system The appropriate system will respond to the ARP request with its hardware address, and communications can begin Unfortunately, ARP traffic can be easily spoofed to reroute traffic from the originating system to the attacker s system, even in a switched environment Rerouted traffic can be viewed using a network packet analyzer and then forwarded to the real destination This scenario is another example of a man-in-the-middle attack and is relatively easy to accomplish Let s take a look at an example

Popularity: Simplicity: Impact: Risk Rating: 4 2 8 5

For this example, we will connect three systems to a network switch The system crush is the default gateway, with an IP address of 10111 The system shadow is the originating host, with an IP address of 101118 The system twister is the attacker s system and will act as the man in the middle Twister has an IP address of 101119 To mount this attack, we will run arpredirect, part of the dsniff package from Dug Song (http://wwwmonkeyorg/~dugsong/dsniff), on twister This package will let us intercept packets from a target host on the LAN intended for another host, typically the default gateway (see Figure 7-3) Be sure to check with your network administrator before trying this technique in your own environment If your switch has port security turned on, you may lock out all users on your switch by trying this attack Keep in mind that we are connected to a switch; therefore, we should only be able to view network broadcast traffic However, using arpredirect, as shown next, will allow us to view all the traffic between shadow and crush On twister we execute the following:

[twister] ping crush PING 10111 from 101119 : 56(84) bytes of data 64 bytes from 10111: icmp_seq=0 ttl=128 time=13 ms [twister] ping shadow PING 101118 from 101119 : 56(84) bytes of data 64 bytes from 101118: icmp_seq=0 ttl=255 time=52 ms

This will allow twister to cache the respective system s hardware address, which will be necessary when executing arpredirect:

[twister] arpredirect -t 101118 10111 intercepting traffic from 101118 to 10111 (^C to exit)

This runs arpredirect and will redirect all traffic from shadow destined for the default gateway (crush) to the attacker system (twister) This is accomplished by arpredirect by replacing the default gateway of shadow to twister, thereby telling the target to send all its traffic to twister first, and in turn twister will send the traffic (after a short sniff or two) out to its intended target Of course, we are effectively turning twister into a router, so we must also turn on IP forwarding on twister to make it act like a router and redirect the traffic from shadow to crush after we have a chance to capture it It is possible to enable

7:

kernel-level IP forwarding on twister, but this is not recommended because it may send out ICMP redirects, which tend to disrupt the entire process Instead, we can use fragrouter (http://packetstormsecurityorg) to easily enable simple IP forwarding from the command line using the B1 switch, as shown here:

[twister] fragrouter -B1 fragrouter: base-1: normal IP forwarding 1011182079 > 192168202021: S 592459704:592459704(0) 1011182079 > 192168202021: P 592459705:592459717(12) 1011182079 > 192168202021: ack 235437339 1011182079 > 192168202021: P 592459717:592459730(13) <output trimmed>

Finally, we need to enable a simple packet analyzer on twister to capture any juicy traffic:

[twister] linsniff Linux Sniffer Beta v99 Log opened [SYN] (slot 1) 101118 => 1921682020 [21] USER ploessel PASS not-very-secret!! PORT 10,1,1,18,8,35 NLST QUIT [SYN] (slot 1) 101118 => 1921682020 [110] USER ploessel PASS g0thacked [FIN] (1)

Let s examine what happened Once we enabled arpredirect, twister began to send forged ARP replies to shadow claiming to be crush Shadow happily updated its ARP table to reflect crush s new hardware address Then, a user from shadow began FTP and POP sessions to 1921682020 However, instead of sending this traffic to crush, the legitimate default gateway, shadow was tricked into sending the traffic to twister because its ARP table was modified to map twister s hardware address to the IP address of crush All traffic was redirected to 1921682020 via twister because we enabled IP forwarding using fragrouter, which caused twister to act as a router and forward all packets In the prior example, we were just redirecting traffic from shadow to crush; however, it is possible to redirect all traffic to twister by omitting the target (-t) option: