[Ettercap][IPtables][Updated]Victim's requests time out!

[SolarCitizen]

Hi evilzone! I'm new here and hopefully you have a solution for the problem I just can't seem to fix alone.

Hardware:
MacBook Pro running OSX and Kali Linux, no VM used.
Wireless card:
Alfa AWUS036NHA


What I'm trying to do is using ettercap to arp poison my Iphone which is on the same network as my Kali booted MBP.

What I did:
1. In /etc/ettercap/etter.conf I changed ec_uid and ec_gid to 0 to enable root on ettercap.
2. Removed the comments on those two ip_table lines .
3. Ettercap seems to automatically handle the ip_forwarding but just to be sure I set it to 1 with "echo 1 > /proc/sys/net/ipv4/ip_forward"
4. I ran ettercap using "ettercap -G"
5. Sniff -> Unified Sniff -> wlan1 (This is my alfa card which runs "Managed mode" according to "iwconfig".
6. Hosts -> scan hosts. Hosts -> host list
7. 192.168.178.1 is my router (target 1) and 192.168.178.65 is my iphone (6 Plus on IOS8.0.2).
8. Mitm -> ARP poisining -> check "Sniff remote connections"
9. Start -> start sniffing

Now I opened e.g. "cnn.com" and all my iphone displays is an error saying Safari couldnt establish any connection to the server.

[Nortcele]

Macs

[SolarCitizen]

Macs

This is actually what I fear...

Ok I did some further digging about HSTS and my IPhone. Apparently Safari has HSTS always enabled (as of Mavericks; iOS 8.x included?) and it cannot be disabled.
I tested twitter.com, google.com, facebook.com, heise.de.
The problem is the whole connection of the victim is getting rekt when I use ARP spoof and I think this is not a problem of HSTS.

[gray-fox]

3. Ettercap seems to automatically handle the ip_forwarding but just to be sure I set it to 1 with "echo 1 > /proc/sys/net/ipv4/ip_forward"

Just making a wild guess here, without thinking this too much, this^ might be the problem. AFAIK when ettercap is started it disables kernels ip forwarding and starts forwarding packets itself.(Like you seemed to notice) So maybe setting forwarding also from "/ proc/sys/net/ipv4/ip_forward" (if you do it after launching ettercap)starts to interrupt ettercap's packet forwarding.

Also checking how packets flow with wireshark could be helpful when "debugging" this kind of issue.

[SolarCitizen]

After letting ettercap handle the ip_forwarding it still doesn't work.

I do further testing (with wireshark) now.

[0E 800]

You need another device to test on to verify if its your setup or if its the device itself.
Sometimes MITM type setups work with some devices and not others.
Some devices connect fine to one AP but can get stuck on another.

[SolarCitizen]

Apparently ettercaps iptable in etter.conf seem not to work. At least they are the reason why the victims url requests time out.

I even commented out those two iptable lines and made my own iptable in a separate terminal using:

iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 8080

Unfortunately  the requests from the victim time out again.


Update: iptables seem not to be the problem. When I first ran ettercap on my fresh installed kali eeepc sslstrip didn't work on mail.yahoo and facebook (I used random usernames and passwords) though both sites were loading.

I totally forgot to set ettercap to root and enable iptables inside etter.conf.

Now I believe the arp poisoning is the problem since I reset etterconf to default and my MBP cant load websites again.

Update:
Kalis /proc/sys/net/ipv4/conf/all/arp_accept is off by default so arp spoofing a Kali machine is unlikely to be successful.
I noticed that most big sites use HSTS to protect them self against sslstrip.
And other sites don't offer a http:// anymore and browser tend to spit out several warnings as soon as they detect sslstrip's self-signed certificates.

My conclusion is ettercap + sslstrip are pretty much dead. Correct me if I'm wrong.
An easier method is a rogue AP/evil-twin + dns spoofing.

P.s.: English is not my native language so please tell me my mistakes so I can wipe them out