Results 1 to 4 of 4

Thread: Latest Kali dsniff issues - no packets in arpspoof

  1. #1
    Join Date
    2016-Oct
    Posts
    15

    Question Latest Kali dsniff issues - no packets in arpspoof

    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

  2. #2
    Join Date
    2016-Oct
    Posts
    15
    Just to shed a little more light onto things...

    Checking TCPDump (I'd argue not as necessary as wireshark confirmed this) but I am getting NO TCP packets passed through - everything suggests ARP poising has worked on Kali just no traffic!

    I've changed root FS back to the original on the Micro (this had the original Kali image and an apt-get update and upgrade) and ran "apt-get install dsniff". After doing this, I get the exact same results as above. So, next step, I used a Kali x64 ISO (kali-linux-2016.2-amd64.iso) I'd downloaded at the same time (about three weeks ago) and have made a live USB. Interestingly, I have the EXACT same problems on a fresh untouched live boot (no updates or persistence etc), does anybody have any possible reasons for this?

    Have tried using ethernet and wireless on both Pi and Live USB although the results are the same.

    Can anybody confirm whether there is a common problem with the dsniff package at the moment i.e. can you do any of this after dist-upgrading if not already done? Was really expecting the Live image to work fine so really really stumped on this now

    Thanks in advanced for any help
    Tommo

  3. #3
    Join Date
    2016-Apr
    Posts
    100
    I upgraded to Bettercap. It's pretty cool. Give it a shot.

    Terminal 1:
    Code:
    apt-get install bettercap
    
    bettercap -I eth0 -X
    Terminal 2:
    Code:
    driftnet -i eth0
    Last edited by P373; 2016-11-09 at 17:47. Reason: wrong command

  4. #4
    Join Date
    2016-Oct
    Posts
    15
    Hey P373 (and everybody else),

    I've actually been away for a little while (some other non related legal matters) but back at my post now . Coming back to this, I decided to do yet another completely fresh install on both the Pi and laptop and to my surprise I am now seeing all packets. I still get the "LUA: no scripts were specified, not starting up" message so it would appear that this is completely unrelated and not an issue at all. Still, would love to know what changed between environments as the network remained the same.

    Just having a play with BetterCap at the moment - very similar and something I will most probably end up using as a complete replacement to ettercap - thank you for the mention

Similar Threads

  1. Raspberry 3 + Latest Kali - Airodump-ng issues
    By e0xbr in forum ARM Archive
    Replies: 17
    Last Post: 2017-10-25, 16:57
  2. Issues with some dsniff tools
    By Flipper in forum General Archive
    Replies: 5
    Last Post: 2016-01-30, 00:28

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •