Thanks for your reply,
Horst Knobloch wrote:
> Pieter Thysebaert <(E-Mail Removed)> wrote:
>
>> even after reading the dsniff FAQ (specifically the bits on arpspoof) I'm
>> still stuck attempting to actually poison some machine's ARP cache:
>>
>> I have 3 GNU/Linux machines : client (10.20.30.1), attacker (10.20.30.2)
>> and server/gateway (10.20.30.3)
>>
>> the 10.20.30.0 network is on eth1 on each machine, eth0 is a control
>> network I have changed the default gateway on both client and attacker to
>> 10.20.30.3,
>> since I understand this is the ARP entry being attacked.
>
> First make sure that your network works fine without spoofing.
> Only if it is working properly go on with arpspoofing.
>
It worked without spoofing, and now works with spoofing too (see below)!
>
>> However, when I issue arpspoof -i eth1 -t 10.20.30.1 10.20.30.3
>> on the attacker, I get "couldn't arp for host 10.20.30.1"
>
>>
>> 18:22:44.659027 arp who-has 10.20.30.1 tell 10.20.30.2
>> 18:22:44.659042 arp reply 10.20.30.1 is-at 0:5:5d:34:25:a7
>> 18:22:44.659119 10.20.30.2.32777 > 10.20.30.1.67: bootp-#133 htype-#86
>> hlen:219 hops:47 xid:0x801033c0 secs:6838 C:1.1.8.10 [|bootp] (DF)
>> 18:22:44.659149 10.20.30.1 > 10.20.30.2: icmp: 10.20.30.1 udp port 67
>> unreachable [tos 0xc0]
> [...]
>> 18:22:49.651213 arp who-has 10.20.30.2 tell 10.20.30.1
>> 18:22:49.651284 arp reply 10.20.30.2 is-at 0:50:ba:be:3d:83
>>
>> I mean, don't the first two lines show that the attacker DOES arp for
>> 10.20.30.1?
>
> It does arp but I can't see the spoofing here. AFAIK the spoofed
> ARP would look like the following in your case:
>
> arp reply 10.20.30.3 is-at 0:50:ba:be:3d:83
>
> where the MAC address must be the MAC address of the attacker.
I have figured out that the bootp packet thing is the way used on linux to
determine the client's MAC (upon receiving the icmp response the client's
mac is stored in the arp cache)
>
>
>> And what's with udp port 67?
>
> BOOTP/DHCP, this is used to configure automatically the IP
> related data for hosts.
Ok, from the source code (arpspoof.c) i take that if __linux__ is defined,
the attacker gets the client's MAC address by looking at the response to
the bootp packet (which, according to ethereal, is a malformed packet)
However, in arp.c (arp_cache_lookup) it seems that only entries wrt eth0 are
looked for in the cache, so my arp entry concerning a machine on eth1 is
ignored...
All seems right now: i have changed eth0 in the code to eth1, and indeed for
most of the time the client's arp entry for the gateway is now poisoned!
Thx,
Pieter
|
Similar Threads
Linear Mode
