Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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
share|improve this question
    
Please provide the output of "arp -n" on both gateway and victim. This will show is cache poisoning was successful at both hosts. –  Dog eat cat world Nov 22 '13 at 6:09
    
I updated the post with the output from the victim you asked, the output from the gateway is not relevant (should it be?) since I'm not poisoning the gateway's arp... I'm just poisoning the victim's arp making it believe I'm the gateway... also: I'm not a security researcher and I'm new to this kind of thing: my setup was simply using my router (which is not powered by dd-wrt or the like) thus I cannot easily access its arp cache –  berdario Nov 23 '13 at 14:23
add comment

1 Answer

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.