meloncholy
May 21st, 2003, 02:59 PM
**disclaimer...seems like I have to put one on all of my posts now....for those that are ready to neg for "this site is not for hacking". This is not hacking. Just a bit of info sharing for those that have been nice enough to throw the green ones my way. Not that I want alot, I guess I need them so I don't get banned.
For all the children who like to neg and call me names for my outspoken and sarcastic posts, you'll probably use this for school. Also, if you don't like my harsh replies (flames) to your stupid posts, stop posting stupid post. (sorry to everyone this does'nt apply to)
I had'nt seen this talked about in detail at all on AO so here is my random experience on the subject with a little background for "push button" kids.
Eavesdropping:
Benefits of sniffing:
Sniffers are used to diagnose network problems, technicians can view packet transmission for troubleshooting. They can be used to monitor traffic as part of day to day network management. They can help show bandwidth use, packet sizes, protocol distro, ect. The IDS boxes most security departments blindly trust primarily rely on sniffing network traffic.
Dangers of sniffing:
Many application protocols (e-mail, IM, telnet, FTP, HTTP) transmit their payloads unencrypted. A lot of authentication exchanges are sent in the clear. Bad guys often install sniffers on compromised hosts. By doing this they can save decoded packets for later retrieval (used to get other usernames and passwords).
Sniffing for newbies
A basic sniffer works on the NIC, it usually filters on its layer 2 address. Layer 2 frames that pass the filter are delivered to the OS. It also passes all broadcast and multicast. Sniffer software obtains frames from the OS and decodes headers and payload for display. The most important thing is that it does not reply to traffic it receives (if you are really paranoid, clipping the transmit wire the Ethernet cable will have the same effect). Sniffers usually have to configure the NIC into promiscuous mode. This is essentially turning off the filtering the NIC does and allows all frames that are visible to the NIC to be passed on to the OS. That being said, sniffers can display frames sent between other systems as long as they are on the same “wire”.
Sniffing Hubs and switches
Hubs are a sniffers friend. All traffic on going thru the hub is repeated out all ports. Any sniffer connected to any hub port sees all traffic on the hub. Switches on the other hand are not sniffer friendly. On a switch, unicast traffic is forwared straight to a single port based on the the destination MAC address. Each port is a separate collision domain. A sniffer connected to a switch will only see the traffic in the prt which it is connected. A lot of (not all) network engineer retards think that switches prevent sniffing. Well, that’s just plain not true. Two ways to get around that are MAC flooding and ARP poisoning.
MAC flooding
The switch relies on the MAC address table, that’s how its able to separate traffic out among the ports. It builds a table by watching source traffic on each port. It then stores that table in dynamic memory. When the address table reaches maximum size some switches stop adding new addresses (can be exploited as a DoS). Other switches “fail open” and essentially turn into a hub. MAC flooding software is pretty easy to create, or probably can be download for you script children. You need to generate a high volume of traffic with random spoofed MAC addresses which exhaust the MAC address table. Like I said earlier, switches that “fail open” can be sniffed like a hub, but this attack should be detectable. Many switch venders are starting to remove that “feature”, exploit, whatever you wanna call it.
Address resolution protocol (ARP)
Hosts send IP traffic to corresponding MAC addresses. Local traffic is sent directly to the MAC address of the destination, while remote traffic is sent to the MAC of the forwarding router. ARP resolves a local IP address to a local MAC address. A ARP request is broadcast while a reply is usually unicast. Replies are cached in an ARP table on each host. ARP cache timeout values vary depending on the different operating systems in use. For example, the default value for NetWare 6 is 5 minutes; FreeBSD is 20
minutes; Windows NT and 2000 is 2 minutes.
ARP poisoning
Bad guy host sends unsolicted ARP replies to a unicast or broadcast address. The claiming victims IP address resolves to the attackers MAC address. One or more hosts will end up with incorrect ARP entries. This can misdirect traffic destined to the victim to the bad guy. This can also be a DoS if the misdirected packets are dropped (in other words no one can send traffic to the victim). The bad guy can now forward traffic to the victim so the victim assumes nothing is wrong. During this the bad guy is sniffing the process. This is basically a one sided man in the middle attack. A full on two way man in the middle attack requires additional ARP replies. The bad guy must spoof the MAC addresses of both the client and the server. Now the bad guy can modify the traffic before it arrives to the legit destination.
OK, if I need to post a follow up post with a step by step I can, but I hope this is clear enough. :)
For all the children who like to neg and call me names for my outspoken and sarcastic posts, you'll probably use this for school. Also, if you don't like my harsh replies (flames) to your stupid posts, stop posting stupid post. (sorry to everyone this does'nt apply to)
I had'nt seen this talked about in detail at all on AO so here is my random experience on the subject with a little background for "push button" kids.
Eavesdropping:
Benefits of sniffing:
Sniffers are used to diagnose network problems, technicians can view packet transmission for troubleshooting. They can be used to monitor traffic as part of day to day network management. They can help show bandwidth use, packet sizes, protocol distro, ect. The IDS boxes most security departments blindly trust primarily rely on sniffing network traffic.
Dangers of sniffing:
Many application protocols (e-mail, IM, telnet, FTP, HTTP) transmit their payloads unencrypted. A lot of authentication exchanges are sent in the clear. Bad guys often install sniffers on compromised hosts. By doing this they can save decoded packets for later retrieval (used to get other usernames and passwords).
Sniffing for newbies
A basic sniffer works on the NIC, it usually filters on its layer 2 address. Layer 2 frames that pass the filter are delivered to the OS. It also passes all broadcast and multicast. Sniffer software obtains frames from the OS and decodes headers and payload for display. The most important thing is that it does not reply to traffic it receives (if you are really paranoid, clipping the transmit wire the Ethernet cable will have the same effect). Sniffers usually have to configure the NIC into promiscuous mode. This is essentially turning off the filtering the NIC does and allows all frames that are visible to the NIC to be passed on to the OS. That being said, sniffers can display frames sent between other systems as long as they are on the same “wire”.
Sniffing Hubs and switches
Hubs are a sniffers friend. All traffic on going thru the hub is repeated out all ports. Any sniffer connected to any hub port sees all traffic on the hub. Switches on the other hand are not sniffer friendly. On a switch, unicast traffic is forwared straight to a single port based on the the destination MAC address. Each port is a separate collision domain. A sniffer connected to a switch will only see the traffic in the prt which it is connected. A lot of (not all) network engineer retards think that switches prevent sniffing. Well, that’s just plain not true. Two ways to get around that are MAC flooding and ARP poisoning.
MAC flooding
The switch relies on the MAC address table, that’s how its able to separate traffic out among the ports. It builds a table by watching source traffic on each port. It then stores that table in dynamic memory. When the address table reaches maximum size some switches stop adding new addresses (can be exploited as a DoS). Other switches “fail open” and essentially turn into a hub. MAC flooding software is pretty easy to create, or probably can be download for you script children. You need to generate a high volume of traffic with random spoofed MAC addresses which exhaust the MAC address table. Like I said earlier, switches that “fail open” can be sniffed like a hub, but this attack should be detectable. Many switch venders are starting to remove that “feature”, exploit, whatever you wanna call it.
Address resolution protocol (ARP)
Hosts send IP traffic to corresponding MAC addresses. Local traffic is sent directly to the MAC address of the destination, while remote traffic is sent to the MAC of the forwarding router. ARP resolves a local IP address to a local MAC address. A ARP request is broadcast while a reply is usually unicast. Replies are cached in an ARP table on each host. ARP cache timeout values vary depending on the different operating systems in use. For example, the default value for NetWare 6 is 5 minutes; FreeBSD is 20
minutes; Windows NT and 2000 is 2 minutes.
ARP poisoning
Bad guy host sends unsolicted ARP replies to a unicast or broadcast address. The claiming victims IP address resolves to the attackers MAC address. One or more hosts will end up with incorrect ARP entries. This can misdirect traffic destined to the victim to the bad guy. This can also be a DoS if the misdirected packets are dropped (in other words no one can send traffic to the victim). The bad guy can now forward traffic to the victim so the victim assumes nothing is wrong. During this the bad guy is sniffing the process. This is basically a one sided man in the middle attack. A full on two way man in the middle attack requires additional ARP replies. The bad guy must spoof the MAC addresses of both the client and the server. Now the bad guy can modify the traffic before it arrives to the legit destination.
OK, if I need to post a follow up post with a step by step I can, but I hope this is clear enough. :)