Ethernet II Switching
This tutorial is all about Ethernet II switching. By the end of this tutorial you should have a decent idea of how to confuse network switches and how to take advantage of that confusion.
Switches are the basic building block of Ethernet II networks. A switch is an intelligent device that maintains a table of MAC address to physical port translation of all connected devices. Based on this list a switch will make port switching (from one port to another) decisions based on the table data collected.
The nature of a switches inherently makes them highly effecive in performance and security over hub installations. A hub is a dumb device, it cannot make decisions. Due to this lack of intelligence ability, every frame recieved must be sent out ALL other ports regardless of destination to be sure the intended destination gets the frame. As you may have already determined, switches eliminate many of the errors inherent in hubs such as:
1) Useless traffic is GREATLY reduced, not all host have to recieve and process the data being sent only to one specific host.
2) Security. Data is only sent to intended destination, tranmission cannot theoretically be sniffed by another member on the same switch.
3) Full-duplex (send and receive at the same time) capability.
Full-duplex 100Mbps connection can theoretically pump 200Mbps when sending and receiving at the same time. Keeping this in mind, I will go over a lab test that I performed just recently (another one syphond): A Catalyst 4006 switch with all ports at 100Mbps full-duplex was used. A port was setup to be the monitor port, all data sent across the switch would be sent out this port. To this port was my laptop running ntop to gather network stats.
I found that I could push a Windows 2000 Pro box to send data at a rate of 91.9Mbps by using three simultaneous files transfers of 840MB each to three other Windows 2000 Pro machines using Microsofts generally regard as shitty SHARE file transfer. This would indicate to me that 100Mbps is a fair representation of what is actually possible on a high end switch. I suspect that I could have pushed the bandwidth usage higher by starting another file transfer but it could not possible reach 100Mbps due to some operational data requiring a chunk of your available 100Mbits. The machine also peaked at 10990packets/sec. Why the hell does that matter? to learn this: you cannot effectively attack high end switches with simple flooding techniques.
2. switching decision process
This post describes how a switch makes switching decisions. Some knowledge of terminology will help.
Since switching is considered a Layer 2 (OSI model) process, it only makes sense that it utilizes MAC addressing to make port switching decisions. A switch learns what machines are connected to each port by listening and logging connections by the source MAC address. If a frame comes in on port 2 with a destination MAC address of 00-00-39-6D-A8-84, the switch logs that MAC to port mapping in memory and remembers this information. As you will see, this caching of MAC/port translations is critical to running successful confusion attacks.
he timeout and refresh interval of the MAC to port translation generally depends on switch model and manufacturer and tends to be only a small factor in swich confusion attacks.
code:
_ _ _ _ _ _
|_|_|_|_|_|_|
1 2 3 4 5 6
^
| – – < - -SOURCE MAC: 00-00-39-6D-A8-84 - < - HOST
In the above diagram the switch will remember the association between port 1 and MAC address 00-00-39-6D-A8-84.
A regular, non-multilayer switch deals only with MAC addresses to make decisions. IP addresses are not used in anyway, shape or form. As you all may or may not know, we generally use IP addresses to refer to boxes. If you want to connect to your local FTP server, you use the IP address, not the MAC address. This bring up the question: “how does a switch know what port to send a packet to if the only information I know is the IP and not the MAC?”. The simple answer is ARP (Address Resultion Protocol).
ARP works by having every TCP/IP capable hosts maintain its own list of IP to MAC translations. When you ping 10.1.1.1 your machine will first check the ARP table to determine which MAC to add to the destination MAC field in ICMP (ping) frame. This is much in the way that a switch maintains its own MAC/port translation.
Using ARP packets, one can tell other hosts which MAC address corresponds to a known IP. In action, ARP packets are used to tell all other hosts on a subnet/segment what MAC you have. ARP packets are broadcast so all memebers of that subnet/segment get them. In practice, they can be used to advertize false IP to MAC translations… think of the potential.
3.ARP spoofing
This chapter we will get down to the fun stuff. I waited some extra time before writing this chapter because I wanted to talk from an experienced point of view and not just blab out a bunch of theory. I actually tried this attack method (ARP spoof) against a small network running two cisco catalyst 2950s and a cisco 2621 router, it works.
ARP spoofing is the act of sending falsified Address Resolution Protocol packets. This attack is commonly refered to as ARP cache poisoning as well as ARP spoofing. I will used these terms interchangably but they pretty much amount to the same thing. Sending these falsified ARP packets are intented to modify the ARP cache of a host(s), thus poisoning it.
The most common and effective way of sending spoofed ARP packets is to use some software, either canned or written yourself. Writing this kind of software is pretty damn easy with perl. In linux, I personally have experience with the send_arp command so I can vouch for it’s functionality. Now some theory:
ARP spoofing is generally used to “take over” IP addresses. By sending an ARP packet with modified contents, one can associate a specified MAC address with a certain IP address in hosts on the local segment. Taking over an IP address has several implications: you can sniff all the data on that segment (theoretically impossible in a switched environment) or you can deny service to all workstations on that segnment. To hijack or take over an IP address, you send an ARP packet with the following fields:
source IP: IP you want to hijack
source MAC: your MAC address
destination IP: depends on victim
destination MAC: depends on victim
Every other field in an ARP packet is fairly inconsequential but they should not be ignored. Experiment with modifying them and you may discover something good. It should be noted that on can use the broadcast MAC address (FF:FF:FF:FF:FF:FF) to victimize all hosts on a segment. At the moment, I need to do more testing to understand how setting the destination IP address will affect the actual destination of the packet. I currently can only theorize about what your system will do (based on local IP to MAC, or ARP cache translations) when setting broadcast, unicast, multicast or malformed IP addresses in the destination IP field.
A real-life example: Sniffing the data on a cable/dsl segment.
To achieve this, we will need some information about the cable/dsl segment and your own computer. This simple information can all be gathered from your local computer.
1. Gateway router’s IP
2. Your MAC address
It should be noted that hijacking the gateway router’s IP will cause ALL segment traffic to try and go *through* your machine. You should be prepared to setup some basic routing/forwarding on your machine so that all clients on the segment will continue to function. If you do not forward the data coming to you, all the connections on that cable segment will die and somebody will notice. This is fairly critical to a successful sniffing session however this short tutorial cannot cover the process of setting up the forwarding on your machine.
Once you have that forwarding setup, you need to find some sniffing software. This kind of software is availble everywhere so it should not be hard to find some. I recommend tcpdump or ethereal. Ok, everything is setup, what happens now? You send the falsified ARP packet and start collecting that data. The ARP packet will consist of the follwing data:
source IP: Gateway router’s IP
source MAC: your MAC address
destination IP: 255.255.255.255
destination MAC: FF:FF:FF:FF:FF:FF
Sending a few of these in a row is generally a good thing to make sure that everyone gets it. *ALL* the data on your cable/dsl segment should now be traversing your machine, getting sniffed by your software and forwarded on to the actual gateway router
BE WARNED: this will get you caught. I do not suggest doing this. I would not do this at my home, if you are unsure, don’t do it at yours. The cable/tel company will find out what is going on pretty quickly when they notice to the gateway is getting ALL data from you and only you.
