arp spoofing

[whistler2008]

My set-up:

1. 2 Ghz cpu, Atheros chipset, Ubuntu -- the "Victim"

2. 1.2 Ghz cpu, rtl chipset, Slackware -- the "Attacker"

3. DSL access point (router)

When I try to arp spoof my "victim", using arpspoof or ettercap, the spoofing
is never effective. In other words, the "victim" always associates, or continues
to associate, with the AP and never with the "attacker"; nor does the
arp cache on the "victim" reveal any assocation with the "attacker".

When i examine the traffic in Wireshark, apparently the packets being sent by
ettercap/arpspoof are fewer & further between than the ones being sent by the
"attacker". also, they never arrive as quickly.

Can anyone tell me a workaround for this other than using a faster cpu than that
of the victim?

thx

[imported_cybrsnpr]

Different O/S's cache arp packets for different intervals. In my experience, *nix (including OS/X) are difficult to arpspoof due to this factor, while Windows are rather easy.

To test the theory, manually clear your arp cache on the victim box and try again.

Another thing to keep in mind...are you sure that arpspoof packets are going out your wireless interface and not a wired interface? Using wireshark, you should see "gobs" of ARP packets flying out the wireless interface.

Could be that your DSL router maintains the state of MAC addresses on various ports (unlikely I know, but still possible). Try powering off the Router to clear state, fire it back up with you already ARP spoofing.

You could also try hooking everything up to a hub for testing purposes, that way you will remove any possibility of a switch (i.e. your DSL router) causing problems.

As for ettercap, can't help there...sorry, I don't use it.

[whistler2008]

My set-up:

1. 2 Ghz cpu, Atheros chipset, Ubuntu -- the "Victim"

2. 1.2 Ghz cpu, rtl chipset, Slackware -- the "Attacker"

3. DSL access point (router)

When I try to arp spoof my "victim", using arpspoof or ettercap, the spoofing
is never effective. In other words, the "victim" always associates, or continues
to associate, with the AP and never with the "attacker"; nor does the
arp cache on the "victim" reveal any assocation with the "attacker".

When i examine the traffic in Wireshark, apparently the packets being sent by
ettercap/arpspoof are fewer & further between than the ones being sent by the
"attacker". also, they never arrive as quickly.

Can anyone tell me a workaround for this other than using a faster cpu than that
of the victim?

thx

cybrsnpr,

ok thanks for the response on this.

yeah i thought that windows might be easier... so im going to test it on a windows box later today.
but i did clear the cache on the Ubuntu box repeatedly but it had no effect. well, i have two wired boxes on my network and occasionally i see the arp cache populated on the Windows box but the packets im trapping on the victim are definitely coming from the bt3 box so ..? but they are hardly "flying out" as you say. in fact there are about 10 times as many ARP packets coming from the router as from the BT3 box? so i guess i should assume there may be a speed issue on my bt3 laptop?

but if clearing the linux cache or restarting the router were required to facilitate it, arp spoofing would lose effectiveness under real world conditions, no?

also, what software do you prefer?

thanks

[imported_cybrsnpr]

in fact there are about 10 times as many ARP packets coming from the router as from the BT3 box? so i guess i should assume there may be a speed issue on my bt3 laptop?

but if clearing the linux cache or restarting the router were required to facilitate it, arp spoofing would lose effectiveness under real world conditions, no?

also, what software do you prefer?

thanks

If your router is shooting that many ARP packets out to the network, you are probably loosing the race

Clearing the cache was only to test your setup.

I prefer the dsniff suite of tools from Dug Song for my MITM/Arpspoofing stuff and the aircrack-ng suite for my wireless deauth/cracking stuff.

But, for those who know how to use ettercap, it works very well.

There are many tools out there that do the same thing. Just find the ones you like and use those. At the end of the day, tools come and go. It's the techniques that stay the same...learn the techniques well and use whatever tool of the day that will accomplish your specific goal.

[whistler2008]

your advice rings true ...

ok im going to delve deeper into ettercap now so I will let you know once i have some useful information. not sure why but both atheros & rtl machines are sending out arp packets about once every 6 to 10 seconds ... obviously much too slow ... im assuming my problem is the configuration ...

thx again & will reply to this thread once i have gained some new data ...

If your router is shooting that many ARP packets out to the network, you are probably loosing the race

Clearing the cache was only to test your setup.

I prefer the dsniff suite of tools from Dug Song for my MITM/Arpspoofing stuff and the aircrack-ng suite for my wireless deauth/cracking stuff.

But, for those who know how to use ettercap, it works very well.

There are many tools out there that do the same thing. Just find the ones you like and use those. At the end of the day, tools come and go. It's the techniques that stay the same...learn the techniques well and use whatever tool of the day that will accomplish your specific goal.

[whistler2008]

To close this thread: i have abandoned ettercap except for purposes of detecting clients who are associated with class c nets. i have found that ettercap's interface is too inconsistent and the host detection process is too time-consuming ... almost 30 mins in a class b.

as usual, the closer you get to the machine, the better the results. arpspoof does a consistently good job across platforms and you can verify the procedure. here's how:

1. after redirecting your ip table (echo 1 > /proc/sys/net/ipv4/ip_forward on linux),
open two terminal windows.

2. in the first: arpspoof -i iface -t router_ip victim_ip
in the 2nd: arpspoof -i iface -t victim_ip router_ip

i know u can do this in one window by redirecting arpspoof's output to the null device but this way you confirm the accuracy of your spoof (MAC addresses) as well as the frequency of your arp packets. this can help if the spoof doesn't succeed due to too slow packet frequency!

also, the arp cache on the victim's machine will confirm the spoof.

thanks everyone for your help on this, particularly cybrsnpr!