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

Discussion in 'Linux Networking' started by Pieter Thysebaert, Sep 24, 2003.

  1. 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, Sep 24, 2003
    #1
    1. Advertisements

  2. First make sure that your network works fine without spoofing.
    Only if it is working properly go on with arpspoofing.

    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?

    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.

    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.

    No.


    Ciao, Horst
     
    Horst Knobloch, Sep 25, 2003
    #2
    1. Advertisements

  3. Thanks for your reply,


    Horst Knobloch wrote:

    It worked without spoofing, and now works with spoofing too (see below)!
    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)
    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
     
    Pieter Thysebaert, Sep 25, 2003
    #3
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.