arpspoof (dsniff) on Debian: can't get it to work

Hello,

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.

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"

the tcpdump trace, listening on eth1 of the client gives

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:45.661103 10.20.30.2.32777 > 10.20.30.1.67: bootp-#133 htype-#86
hlen:219 hops:47 xid:0x801833c0 secs:26899 C:1.1.8.10 [|bootp] (DF)
18:22:45.661113 10.20.30.1 > 10.20.30.2: icmp: 10.20.30.1 udp port 67
unreachable [tos 0xc0]
18:22:46.671163 10.20.30.2.32777 > 10.20.30.1.67: bootp-#133 htype-#86
hlen:219 hops:47 xid:0x801133c0 secs:6805 C:1.1.8.10 [|bootp] (DF)
18:22:46.671171 10.20.30.1 > 10.20.30.2: icmp: 10.20.30.1 udp port 67
unreachable [tos 0xc0]
18:22:47.681177 10.20.30.2.32777 > 10.20.30.1.67: bootp-#133 htype-#86
hlen:219 hops:48 xid:0x801033c0 secs:6804 C:1.1.8.10 [|bootp] (DF)
18:22:47.681186 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?

And what's with udp port 67?
Should anything on the client machine actually be listening on port 67 for
arpspoof to work?

BTW this is dsniff 2.4b1 on a Debian GNU/Linux 3.0 installation.

Pieter

Pieter Thysebaert <pieter.thysebaert@rug.ac.be> 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.


> 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"

According the FAQ, this error normally indicates that the target
host is not in the same network as the attacker. Check with
ifconfig your netmasks. They should be the same on all three
machines for eth1 (I think you want to use 255.255.255.0 here).

BTW: what network have you assigned to the eth0 interfaces?


> the tcpdump trace, listening on eth1 of the client gives
>
> 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.


> And what's with udp port 67?

BOOTP/DHCP, this is used to configure automatically the IP
related data for hosts.

In your case above client 10.20.30.2 ask 10.20.30.1 for IP
configuration data. However 10.20.30.1 doesn't answer because
there is no related server running.

However what puzzles me a little bit is that the BOOTP packet
trace looks broken. It is not broadcasted, unknown/invalid
HW type, hop count very high, secs since reboot greater 60.
Verify with ethereal whether tcpdump displays this correctly.

Nevertheless check network config on 10.20.30.1 and disable
BOOTP/DHCP if it is enabled.


> Should anything on the client machine actually be listening on port 67
> for arpspoof to work?

No.


Ciao, Horst
--
»When pings go wrong (It hurts me too)« E.Clapton/E.James/P.Tscharn

Thanks for your reply,


Horst Knobloch wrote:


> Pieter Thysebaert <pieter.thysebaert@rug.ac.be> 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