Friends,
Lets study this topic and try to understand...
Introduction A computer connected to an IP/Ethernet LAN has two addresses. One is the address of the network card, called the MAC address. The MAC, in theory, is a globally unique and unchangeable address which is stored on the network card itself. MAC addresses are necessary so that the Ethernet protocol can send data back and forth, Independent of whatever application protocols are used on top of it. Ethernet builds “frames” of data, consisting Of 1500 byte blocks. Each frame has an Ethernet header, containing the MAC address of the source and the Destination computer.
The second address is the IP address. IP is a protocol used by applications, independent of whatever Network technology operates underneath it. Each computer on a network must have a unique IP address to Communicate.
IP and Ethernet must work together. IP communicates by constructing “packets” which are similar to frames, but have a different structure. These packets cannot be delivered without the network layer. In our case they are delivered by Ethernet, which splits the packets into frames, adds an Ethernet header for delivery, and sends them down the cable to the switch. The switch then decides which port to send the frame to, by comparing the destination address of the frame to an internal table which maps port numbers to MAC addresses. When an Ethernet frame is constructed, it must be built from an IP packet. However, at the time of construction, Ethernet has no idea what the MAC address of the destination machine is which it needs to create an Ethernet header. The only information it has available is the destination IP from the packet’s header. There must be a way for the Ethernet protocol to find the MAC address of the destination machine, given a destination IP. This is where ARP, the Address Resolution Protocol, comes in.
the Address Resolution Protocol, to resolve IP addresses into hardware, or MAC (Medium Access Controllers), addresses. All the hosts in the LAN keep a cache of resolved addresses. ARP resolution is invoked when a new IP address has to be resolved or an entry in the cache expires. The ARP poisoning attack consists of maliciously modifying the association between an IP address and its corresponding MAC address.
Although this is the most popular version, ARP poisoning is not connected to Ethernet networks. Layer 2 switched LANs, 802.11b networks, and cryptographically protected connections are also vulnerable.
ARP spoofing
For my example we will connect 3 systems to the network switch. The system “HDB” is the default gateway. The IP of the default gateway is 10.0.2.121. The System “HD” is the Originating host, the IP of “HD” is 10.0.2.211. “ARBU” is the attack host, The IP of “ARBU” is 10.0.2.233, “ARBU” will act as our “Man in the Middle”. To launch our Attack we will need to run ARP Redirect, Part of the dsniff package available from Dug Song (http://www.XYZ.org/~ABC/dsniff), on ARBU. The package will let us intercept the packets from a target host on the network intended for another host,
Typically the default gateway. Remember we are connected to a switch; We should only be able to see network broadcast traffic. Using ARP Redirect however will allow us how to view all the traffic between
HD and HDB. On “ARBU” execute the following Commands:
[root@ARBU @ ~] ping HDB
PING 10.0.2.121 from 10.0.2.233 : 56(84) bytes of data.
64 bytes from 10.0.2.121L icmp_seq=0 ttl=128 time=1.3 ms
[root@ARBU @ ~] ping HD
PING 10.0.2.211 from 10.0.2.233 : 56(84) bytes of data
64 bytes from 10.0.2.211: icmp_seq=0 ttl=255 time=5.2 ms
This will allow ARBU to cache the target hardware address, this will be required when executing our redirect :
[root@ARBU @ ~] arpredirect -t 10.0.2.211 10.0.2.121
intercepting traffic from 10.0.2.211 to 10.0.2.121 (^c to exit)…
This will run our ARP Redirect and will redirect all traffic for the gateway (HDB) to the attacker (ARBU). This is done by arp redirect by replacing the default gateway of HD to ARBU, thus telling the target to send all of the traffic to ARBU first, in turn ARBU will send the traffic (Once sniffed through) to the intended target. In effect ARBU is turned into a router and will redirect the traffic from HD to HDB so we must make it act like a router and enable IP forwarding on ARBU so it can redirect the traffic to HDB once it has been captured by ARBU. Instead of using Kernel-level IP forwarding we use fragrouter as kernel-level may send out ICMP redirects and can disrupt the process. fragrouter will allow us to easily enable simple IP forwarding from command line using the -B1 Switch as shown.
[root@ARBU ~] fragrouter -B1
10.0.2.211.2079 > 192.168.20.20.21: S 592459704:592459704(0)
10.0.2.211.2079 > 192.168.20.20.21 : P 592459705:592459717(12)
10.0.2.211.2079 > 192.168.20.20.21 : . ack 235437339
10.0.2.211.2079 > 192.168.20.20.21 : P 592459717:592459730(13)
(output trimmed)
Finally we need to enable a packet analyzer on ARBU to capture any traffic worth
sniffing out.
[root@ARBU ~] linsniff
Linux Sniffer Beta v.99
Log opened.
———[SYN] (slot 1)
10.0.2.121 => 192.168.20.20 [21]
USER UltimA
PASS lol.you.got.owned
PORT 10,1,1,18,8,35
NLST
QUIT
———[SYN] (slot 1)
10.0.2.121 => 192.168.20.20 [110]
USER UltimA@HD.com PASS ARBU.pwned.Me
[FIN] (1)
Lets examine what happened. Once ARPRedirect was enabled, ARBU began to send
spoofed ARP replied to HD claiming to be HDB. HD(Being Retarded) happily updated the ARP Table to reflect HDB’s new Hardware address. Then a HD user stared an FTP Connection and a POP session to 192.168.20.20 and the USER and PASS was logged by the sniffer. In the last example we were only redirecting traffic from HD to HDB; However if we miss the -t switch in the arpredirect command we can redrect ALL traffic on the network
ARP Poisoning attacks
Sniffing
Switches determine which frames go to which ports by comparing the destination MAC on a frame against a table. This table contains a list of ports and the attached MAC address. The table is built when the switch is powered on, by examining the source MAC from the first frame transmitted on each port. Network cards can enter a state called “promiscuous mode” where they are allowed to examine frames that are destined for MAC addresses other than their own. On switched networks this is not a concern, because the switch routes frames based on the table described above. This prevents sniffing of other people’s frames. However, using ARP spoofing, there are several ways that sniffing can be performed on a switched network. A “man-in-the-middle” attack is one of these. When a MiM is performed, a malicious user inserts his computer between the communications path of two target computers. Sniffing can then be performed. The malicious computer will forward frames between the two target computers so communications are not interrupted. The attack is performed as follows (where ARBU is the attacking computer, and JIM and USMANI are targets):
-ARBU poisons the ARP cache of USMANI and JIM.
-USMANI associates JIM’s IP with ARBU’s MAC.
-JIM associates USMANI’s IP with ARBU’s MAC.
-All of USMANI and JIM’s IP traffic will then go to ARBU first, instead of directly to each other.
This is extremely potent when we consider that not only can computers be poisoned, but Routers/gateways as well. All Internet traffic for a host could be intercepted with this method by performing a MiM(man in the middle ) on a target computer and the LAN’s router.
Another method of sniffing on a switched network is MAC flooding. By sending spoofed ARP replies to a switch at an extremely rapid rate, the switch’s port/MAC table will overflow. Results vary by brand, but some switches will revert to broadcast mode at this point. Sniffing can then be performed.
DOS
Updating ARP caches with non-existent MAC addresses will cause frames to be dropped. These could be sent out in a sweeping fashion to all clients on the network in order to cause a Denial of Service attack. This is also a side effect of post-MiM attacks, since targeted computers will continue to send frames to the attacker’s MAC address even after they remove themselves from the communication path. To perform a clean MiM attack, the target computers would have to have the original ARP entries restored by the attacking computer.
Hijacking
Connection hijacking allows an attacker to take control of a connection between two computers, using methods similar to the MiM attack. This transfer of control can result in any type of session being transferred. For example, an attacker could take control of a telnet session after a target computer has logged in to a remote computer as administrator.
Cloning
MAC addresses were intended to be globally-unique identifiers for each network interface produced. They were to be burned into the ROM of each interface, and not be changed. Today, however, MAC addresses are easily changed. Linux users can even change their MAC without spoofing software, using a single parameter to “ifconfig”, the interface configuration program for the OS. An attacker could DoS a target computer, then assign themselves the IP and MAC of the target computer, receiving all frames intended for the target.
Tools Used
ARPOISON
ETTERCAP
PARASITE
Cain and Able
Defense
A possible defense against ARP poisoning is using static entries in the ARP cache. Static entries cannot be updated by ARP replies and can be changed only manually by the system administrator. Such an approach however is not viable for networks with hundreds of hosts because those entries must be inserted manually on each host. Automating such a solution via a network script is not recommendable Since it relies on higher levels of the ISO/OSI stack. Relying on higher levels when the data link layer has not been secured yet may be dangerous because the protocol used to exchange the list can be hijacked using ARP poisoning before the list is distributed. Even worse, some operating system (such as Windows) may accept dynamic updates even if an entry is set as static, thus making static Ethernet routing useless.
Port security, Is another mechanism for tackling the problem. It is a feature present in many modern switches that allows the switch to recognize only one MAC address on a physical port. This is often suggested as an effective protection against ARP poisoning, but it is not. If the attacker does not spoof its own MAC address, it can poison the two victims’ cache without letting the switch interfere with the poisoning process.
Besides static cache entries and port security, the only other defense that will not modify ARP behavior is detection. IDS and personal firewalls usually notice the ARP switch and warn the user that the entry in the cache is changed. As it often happens in the computer security domain, the decision is left to the user and his/her awareness. Given the particularly sophisticated level of operation in this case, we doubt the average user will take the proper actions.
Some kernel patches exist that try to defend against ARP poisoning. .Anticap. Does not update the ARP cache when an ARP reply carries a different MAC address for a given IP from then one already in cache and will issue a kernel alert that someone is trying to poison the ARP cache. Such a solution is against ARP definition itself, since it drops legal gratuitous ARP.
When a new ARP replies announcing a change in a (IP, MAC) pair is received, it tries to discover if the previous MAC address is still alive. If the previous MAC address replies to the request, the update is rejected and the new MAC address is added to a list of banned Addresses.
In a solution that implements two distinct queues, for requested addresses and received replies, is roposed. The system discards a reply if the corresponding request was never sent, i.e., is not in the queue, and in the received queue an IP address associated with a different Ethernet address is already present.
All these solutions have the same problem. If the malicious ARP reply is sent before the real one is put in the cache, for a real request, the victim caches the wrong reply and discards the real one. A race condition exists between the attacker and the victim. When the first ARP request is broadcast, both the victim and the attacker receive the message. The first one who replies will take over the other forever. Furthermore, the attacker could also spoof an ICMP echo request message and immediately send after
it a false ARP reply. When the victim receives the ICMP echo request, it performs an ARP request, but the false reply is already in its queue of received packet, so it accepts it a valid one. If Antidote is installed, a host can spoof the sender MAC address and force a host to ban another host. Solutions such as a centralized ARP cache or a DHCP server broadcasting ARP information, as they are deployed
in IP over ATM networks [8], have not been considered as the attacker could spoof the source of the broadcast and poison the whole LAN. A digitally signed or MAC-ed broadcast packet would not be vulnerable to spoofing, yet broadcasting ARP tables could generate large traffic on the LAN. Since an entry for each host needs to be broadcast, on large networks this will generate considerable traffic and every host would have to store the entire ARP table even if it might not be needed at the moment. The main problem with centralized ARP cache is that if a host goes down, the central server will not notice the event. Thus, when a host that wishes to communicate with the one currently down asks for ARP information to the central server, it will receive the information even if the host is down. At this point an attacker could impersonate the offline host using its MAC address and receive all the packets sent to it.
Reference –
intro to arp poisoning by Sean Whalen
www.rootsecure.net/content/downloads/pdf/arp_spoofing_intro.pdf
S-ARP: a Secure Address Resolution Protocol by D. Bruschi, A. Ornaghi, E. Rosti
www.milw0rm.com/papers/267
ALSO I WOULD LIKE TO THANX ShoKz, JR, ReMuSoMeGa , Mad-Hatter, UltimA , str0ke , IDU , l33t , n0f34r....
Read It And Post It.............
