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.
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.
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.
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.
May 21st, 2003 03:06 PM
rock on melon, i like the tutorial... a good read for newbies like me
May 21st, 2003 03:07 PM
I guess it should be noted:
If a machine is compromised on the same segment as a server, and the attacker can DoS the server or prevent it from responding in a timely manner, they may be able to set up a "fake" server which takes over the identity of the server and captures authentication credentials, etc going to it.
How easy this is depends on protocols, and how easy it is to DoS a genuine server.
On protocols which use challenge/response, someone setting up a fake server can do man-in-the-middle attacks to obtain a session with the credentials of someone else. This is generally considered bad.
The "fake server" is similar to sniffing, but does not rely on unswitched networks or promiscuous mode (typically)
May 21st, 2003 04:16 PM
Nice tut, meloncholy,
That's partially true. Indeed multicast & broadcast are flooded over the bridge. An malicious attacker can grab info about routing protocol of spanning tree protocol.
Originally posted here by meloncholy
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.
If the bridge is not properly configured for disabling STP on port dedicated to hosts, the attacker can force a lot of traffic to go through its own terminal.
This is described in a tut I wrote few month ago on the same subject http://www.antionline.com/showthread...hreadid=237836
That subject is often ignored by admin that focus on Layer 3 & 4 security, but a weak mac layer would compromise all.
Good job hope your post readers will understand that!
[shadow] SHARING KNOWLEDGE[/shadow]
May 21st, 2003 04:24 PM
Sorry I didn't see your Tut earlier Networker. That was a nice post! A bit more detailed than mine, but hopefully I got the point accross in this one as well. I did a search for "man in the middle" on AO before I wrote this and didn't really see too much, but your post didn't come up on that search. I'll just have to search a bit more before I post another Tut so there is no duplication,
May 21st, 2003 04:29 PM
Slartly: u r absolutly right, it's smth to sniff & it's another to usurpe identity.... but for a ssh connexion the client can make sure that the server is who it says but not reciprocally.
Sniffing the connexion could allow an attacker to grab the login/password of a client to access sensitive data.
This had been discussed here
MC: There is no pb dude!
It's always a good thing to recall anyone mac layer threats !!!
As I said to manies ignore those
[shadow] SHARING KNOWLEDGE[/shadow]
May 21st, 2003 06:10 PM
Check out Ettercap if you run linux and want to see the old monkey-in-tha-middle attack at work. ARP posioning is also a concern for wireless networks joined to conventional LANs with hubs and not routers.
\"If computers are to become smart enough to design their own successors, initiating a process that will lead to God-like omniscience after a number of ever swifter passages from one generation of computers to the next, someone is going to have to write the software that gets the process going, and humans have given absolutely no evidence of being able to write such software.\" -Jaron Lanier
May 21st, 2003 06:23 PM
Ettercap would do the trick. Now that is one nasty tool!
a little off this subject, but since you brought up wireless.....
You can now buy jammers (a bit bigger than a bottle cap) that can bring down a WAP in a second. The kill radius is something like 100m. They are totally illegal in the US (any jamming device is) and are easily dedected by a spectrum analyzer and antenna. But for the time they are working, the wireless network would be totally useless.
May 21st, 2003 08:12 PM
I agree this is a good Tut . Very usefull and right on information. Greenies of everyone!!!!. Am looking forward in seeing you post again.
May 28th, 2004 04:31 PM
Can u explain the sniffing process by a using a tool and show a example?