Hey all,

I've posted in this forum as after searching around, I've seen a few other simialr issues (more at the bottom) relating to other architectures and setups, please advise if it's in the wront place though.


Problem: I am not able to see any traffic while performing an arp spoof using a number of tools although arp poisoning appears successful on target machine(s).


Setup: I'm using the latest image (kali-2.1.2-rpi2.img) of Kali (Kali GNU/Linux Rolling) ARM for Raspberry Pi 2 onto an 8GB Micro. When booting the Pi 2 for the first time, I ran "apt-get update && apt-get upgrade -y" without any problems. I've then attached a 120GB USB drive and used the adafruit-RootHelper script to Rsync the root fs to the drive and manually modified fstab and cmdline.txt to reference PARTUUID. After another reboot, I ran "apt-get install kali-linux-full" (my net connection tops out at around 350KBps so this takes a long time!). The Pi is connected to a local switched LAN via ethernet cable (showing as eth0) , only wireless KB/Ms dongle and HDD attached via USB. IP of router is 192.168.1.1, IP of target is 192.168.1.157 and IP of Kali machine is 192.168.1.175.


Details
Around 3 weeks ago, I used the exact process as above to setup Kali linux on a Raspberry Pi 2. As soon as it had finished, I began to play and had 100% success with sniffing packets with arp poisoning. To do this, I first of all used ettercap-graphical (Options: Check Promisc mode > Sniff: Unified sniffing > Network interface: etho > Hosts: Scan for hosts > Hosts: Host List > Right Click 192.168.1.1: Add to target 1 > Right Click 192.168.1.157: Add to target 2 > (Check Targets in Targets>view targets) > Mitm: ARP Poisoning > Check Sniff remote connections (OK) > View > Connections). At this point, my window was instantly filled with UDP and TCP traffic between the targets.

After this, I attempted the same with the following commands which also worked brilliantly, throwing no errors or problems (wan't to get things working before introducing SSLStrip)...

Terminal Window 1:
Code:
echo 1 > /proc/sys/net/ipv4/ip_forward
Code:
arpspoof -i etho -t 192.168.1.1 192.168.1.157
Terminal Window 2:
Code:
arpspoof -i etho -t 192.168.1.157 192.168.1.1
Terminal Window 3:
Code:
urlsnarf -i eth0

A few days after exploring the above, I ran apt-get dist-upgrade which made a number of changes. Immediately after this, I would no longer see any traffic in urlsnarf or wireshark (driftnet -i eth0 no longer shows any images either). ettercap-graphical only shows a handful of UDP packets with the host being either 192.168.1.1 or 192.168.1.157 (either of the targets). The target machine is running Windows 10 and arp -a in CMD shows a successful ARP poison. After shutting down the attack, the table is corrected.

I don't know enough about this so any insight would really be appreciated, I now have a line in ettercap-graphical on startup that states "LUA: no scripts were specified, not starting up" which was not present when this worked.

Might also be worth noting, if I attempt this and do not forward ipv4 or only spoof one way, the target system remains stably connected to the internet - there is no apparent loss of connection at any point which there should be (does this mean that despite the arp table showing the spoof on the target system, spoofing is not actually successful?).



What I've done:
> First tried purging the packages and reinstalling. Exact same problem.
> Rebuilt ettercap-graphical from source and installed. Exact same problems (at this point, I mistakenly thought is was an ettercap issue)
> Checked sources.list and compared against the official recommendations - all ok.
> Started from scratch yesterday (Sun 6th Nov). I repeated the exact same setup expecting the same results. Instead, this didn't work and I've got the exact same issues on a fresh setup.



Now What:
After some searching, I've come across a thread at https://forums.kali.org/showthread.p...light=arpspoof and one at https://forums.kali.org/showthread.p...r-distro-issue.

These seem to suggest that the cause is related to the package dsniff, more precisely, dsniff=2.4b1+debian-22. All info seems to suggest that purging this and using dsniff=2.4b1+debian-18 resolves these issues.

Does anybody have any insight into this and what exactly the issue is with the latest dsniff package that results in this behavior if this is indeed the reason why and if not, what else could be causing this? More importantly at this stage, can anybody advise on the best / safest way to downgrade dsniff to see if this corrects the problem - the approach described in my second link only provides the newer version so not a suitable approach; not too keen on messing with sources if I can avoid it either?

I know there seems to be a lot of these types of problems out there, if anybody has any advice or some steps so start identifying what is going wrong, I would really appreciate your help

Tommo