Why am I unable to connect to an address spoofed with arpspoof?

Question

I wanted to see how many combinations of websites and browsers are still vulnerable to a tls stripping attack (like, by implementing HSTS or disabling cleartext HTTP altogether). To do it I wanted to see it firsthand by using the sslstrip tool, but I was unable to get it working (by following the instructions on the project page itself): the ARP spoofing apparently is working fine, since the target pc cannot browse anymore, but sslstrip doesn't receive anything.

I tried to listen with a TCP socket on the port redirected by iptables, but I received nothing, so I excluded also iptables, and now I'm just trying to receive connections directly on the port used by the victim client. I tried by both enabling and disabling ip forwarding (with /proc/sys/net/ipv4/ip_forward), and using wifi or ethernet as the interface from the attacking host, but nothing changes:

This is the command I'm using from the attacking host (address 192.168.1.33 hostname macbook, a Linux 3.11 box):

sudo arpspoof -i eth0 -t 192.168.1.31 192.168.1.1

(192.168.1.1 is the gateway) and then

sudo socat TCP4-LISTEN:80 STDOUT

on the victim host (192.168.1.31):

socat - TCP4:192.168.1.1:80

I can open the connection, but if I try anything, I don't receive anything on the attacking host (pointing socat to the attacker's ip address obviously works)

traceroute shows that apparently the ARP spoofing is successful:

> traceroute 192.168.1.1
traceroute to 192.168.1.1 (192.168.1.1), 30 hops max, 60 byte packets
 1 macbook.local (192.168.1.30) 2.719ms 5.932ms *
 2 * * *
 3 * * *
 4 * * *
 5 * * *
 [snip]
28 * * *
29 * * *
30 * * *

arp -n output from the victim host

Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.1.33             ether   00:1d:4f:fc:af:fc   C                     wlan0
192.168.1.1              ether   00:1d:4f:fc:af:fc   C                     wlan0

Answer 1

There's an IP collision going on. Although you've convinced 192.168.1.31 that you're 192.168.1.1 with the following command (meaning you've influenced its routing table):

sudo arpspoof -i eth0 -t 192.168.1.31 192.168.1.1

... the 192.168.1.1 still thinks its 192.168.1.1, so when it sees arp requests for its own IP both your machine and the router will respond with a MAC address. The first MAC address received will be the one to get the packet (don't think that because you see an entry for your poisoned IP in arp -n that arp requests for that IP will necessarily cease). Also, it doesn't know NOT to send packets to the victim machine, or to respond to other packets that appear to come from that machine.

Typically, man-in-the middle is just that, "in the middle" so you should try the following:

sudo arpspoof -i eth0 -t 192.168.1.31 192.168.1.1

sudo arpspoof -i eth0 -t 192.168.1.1 192.168.1.31

The second one tells your router to send packets addressed to IP 192.168.1.31 to you (rather than the original victim machine). If your victim machine gets a packet from the real 192.168.1.1 with the real MAC address of that machine, do you know what it's behaviour will be? So it's best to avoid this possibility by redirecting any packets from the real 192.168.1.1 destined to 192.168.1.31 to you, since you're suppose to be in the middle.