[转载]ARP Spoofing: know it to use it
ARP Spoofing: know it to use it文章作者：Null
信息来源：邪恶八进制信息安全团队（[url]www.eviloctal.com[/url]）
-[ SUMMARY ]---------------------------------------------------------------------
0x01: Introduction
0x02: Networking concepts
0x03: Implementation of ARP protocol
0x04: ARP Spoofing
0x05: Examples
0x06: Use and abuse
0x07: Possible solutions
---------------------------------------------------------------------------------
---[ 0x01: Introduction ]
The tecnique of ARP-Spoofing (also called ARP-Poisoning) is the most simple and
efficent method to perform a Man-In-The-Middle attack (MITM) in a swiched LAN
and other interesting stuff.
Now I will explain how it works and the possible implementation of this tecnique.
Thanks: thanks to Nexus that has reviewed this article to correct my bad english
and to everybody who contributes to this site with their knowledge and questions
that has convinced me to write this paper.
Last but not at least lot of thaks to ALoR and NaGA, the creators of the Ettercap
project and for their tutorials from which i've been inspired to write this paper.
This document may contain errors (a lot I think :-) ). I' ll be grateful to you
if you will feedback them at null @ playhack . net.
-----------------------------------------------------------------------------[/]
---[ 0x02: Networking concepts ]
The ARP is a protocol located to the level 3 of the ISO-OSI stack.
His aim is to associate an IP address to a MAC address: this is formed by 48
bits that describe in an univoque way every network card in the world.
This is necessary to permit local routing, in a group of computers that belong to
the same network.
When the association is made, the packets can be sent and received by
the right target.
ARP protocol provides two types of messages:
a) ARP request: when the sender asks for the MAC address associated by a specific
IP address (generally it is sent in broadcast).
b) ARP reply: sent as reply to an ARP request and indicates the MAC address of
the host specified.
These operations are made by operative systems that, moreover, save this
informations for a while in a table, called ARP cache.
His objective is to improve the performances of the network, as velocity (the
packets can be routed immediately without waiting for the reply from the other
host), and as occupation of bandwith (for each packet to send we could need an
ARP request and an ARP reply).
-----------------------------------------------------------------------------[/]
---[ 0x03: Implementation of ARP protocol ]
Sending an IP packet: the kernel searches in the ARP cache if is stored the MAC
address associated with the destination IP. If it is,
builds the ethetnet frame and sends it. If the entry
isn't present, send an ARP-Request and wait for the answer.
Arrive of an ARP-Reply: if the answer comes after the request, it will be saved
immediately in the cache.
Generally are accepted also the ARP-Replies not requested,
but only if their entry is already stored in cache.
Otherwise it will be dropped.
Arrive of an ARP-Request: the kernel answers with an ARP-Reply. In most cases,
the operative system saves in cache the association by
MAC and IP of the sender.
This is done, for example in Linux systems.
To motivate the last behaviour, if we open the file "ARP.c"
(/net/ipv4/ARP.c in the linux kernel tree) we can see:
/*
* Process entry. The idea here is we want to send a reply if it is a
* request for us or if it is a request for someone else that we hold
* a proxy for. We want to add an entry to our cache if it is a reply
* to us or if it is a request for our address.
* (The assumption for this last is that if someone is requesting our
* address, they are probably intending to talk to us, so it saves time
* if we cache their address. Their address is also probably not in
* our cache, since ours is not in their cache.)
*
* Putting this another way, we only care about replies if they are to
* us, in which case we add them to the cache. For requests, we care
* about those for us and those for our proxies. We reply to both,
* and in the case of requests for us we add the requester to the ARP
* cache.
*/
The motivation is simple: with this method we could save time and bandwith.
It seems to be applied also in Windows systems, but it is only my opinion,
I' haven't seen the source code... :-)
-----------------------------------------------------------------------------[/]
---[ 0x04: ARP Spoofing ]
There are two methods to accomplish the attack.
1) If we use the ARP-Replies, we will send it with the same IP address of the
machine we would take place, and as MAC the same of the attacker.
However, remembering the kernel specifications, if the entry isn't present
in cache yet, it won't be inserted.
A possible solution is to send an ICMP ECHO REQUEST (ping) with sender IP spoofed
from the machine we would take place. To reply to ping, the victim add to his
ARP cache the correct entry.
After that we can poison it, sending the fake ARP-Reply.
But this work-around fails if the victims have the ping service down...
2) The second solution consists in using the ARP-Request. Following the kernel
directives explained above, we know that the entry will be inserted immediatley
when a request is received. Without work-arounds...
The only difference with the previous tecnique is that we have to modify the ethernet
header of the packet, changing the destination MAC (by default set to broadcast)
to the MAC Address of the victim.
This is made because if we send in broadcast this packet, we will modify ALL the
caches of machines connected at our lan. And, of course, we wouldn't this for
now... :-)
After that we will receive all the traffic by the victim directed an received to
the spoofed host.
But we also have to forward the packets captured in order to keep alive the connection
between the two machines. (For example using the IP_FORWARD feature of the kernel).
-----------------------------------------------------------------------------[/]
---[ 0x05: Examples ]
1) Network status.
+--------+ +--------+
| HOST A |----------------------------->| HOST B |
|(victim)|<-----------------------------|(victim)|
+--------+ +--------+
^ ^
| |
| +----------+ |
|----------->| HOST C |<--------------|
|(attacker)|
+----------+
Victim A: IP = 192.168.0.1; MAC = 00:14:C1:3F:C6:C4
Victim B: IP = 192.168.0.2; MAC = 00:11:F0:6A:DE:F6
Attacker C: IP = 192.168.0.5; MAC = 00:13:A0:8A:D3:A1
2) First attack using ARP-Reply (packets sended by attacker).
C ---> A : (IP B) is at (MAC C)
C ---> B : (IP A) is at (MAC C)
3) Second attack using ARP-Request (packets sended by attacker).
C ---> A : Who has (IP A) tell (IP B) at (MAC C)?
C ---> B : Who has (IP B) tell (IP A) at (MAC C)?
4) ARP caches of victims BEFORE attack.
+------------------------------------------------------------+
|Host A: |
| # ARP -na |
| ? (192.168.0.2) at 00:11:F0:6A:DE:F6 [ether] on eth0 |
+------------------------------------------------------------+
+------------------------------------------------------------+
|Host B: |
| # ARP -na |
| ? (192.168.0.1) at 00:14:C1:3F:C6:C4 [ether] on eth0 |
+------------------------------------------------------------+
5) ARP caches of victims AFTER attack.
+------------------------------------------------------------+
|Host A: |
| # ARP -na |
| ? (192.168.0.2) at 00:13:A0:8A:D3:A1 [ether] on eth0 |
+------------------------------------------------------------+
+------------------------------------------------------------+
|Host B: |
| # ARP -na |
| ? (192.168.0.1) at 00:13:A0:8A:D3:A1 [ether] on eth0 |
+------------------------------------------------------------+
-----------------------------------------------------------------------------[/]
---[ 0x06: Use and abuse ]
Now we learnt how we can modify the ARP cache of our victims. But what we
can do with that?
Uhm... We can use the fantasy!
1) MITM attack: ARP Poisoning is the best way to realize that attack in a
switched LAN.
To insert into two victims we can use the method standard described above,
but with a litte modify we can act by gateway for the network!
If we use ARP-Request to make the attack, we will only have to set the
"destination MAC address" of ethernet header to send in broadcast our request.
All the machines on the network hear our packet and update their caches.
Obviously, we have to forward the packets to the correct gateway to keep
active the connection of victims.
2) DoS attack: if we modify the ARP cache of the victim(s) rewritting the MAC
of their gateway with a non-existent address, it won't be able to connect
to external networks.
3) Our fantasy...
Note:
The tool "Sniff_server" (available in the section "Tools" of playhack.net) use the
tecnique of sending fake ARP-Requests to perfotm the MITM attack.
-----------------------------------------------------------------------------[/]
---[ 0x07: Possible solutions ]
To avoid ARP Poisoning attack, we can use static ARP in each host of the network.
But if the IP addresses is assigned dynamically by DHCP, or we have a big network,
this solution cannot be applied.
Tools like ettercap, ARPwatch or IDS can notice the attack, but can't avoid them.
-----------------------------------------------------------------------------[/]
\======================================[EOF]=====================================/
页:
[1]