Burp suite interception bypass

Question

I am trying to intercept application layer traffic using network level attacks. In particular, I have stumbled across this interesting article here.

Link

Briefly, it uses ARP poisoning to make attacker's machine mitm and uses iptables to forward http and SSL traffic to burp on the attacker's machine.

My setup:

1. OnePlus X with hotspot as the router
2. Windows 10 32 bit PC as the victim (Various browsers running)
3. Kali Linux 2018 64 bit PC as the attacker(Wireshark, burp suite and ARP spoof running)

All works well and fine, ARP poisoning does its job and I can see the packets in Wireshark. All the DNS requests made and all unencrypted HTTP data are visible in Wireshark. Also, burp is setup fine and intercepts traffic, even HTTPS traffic. For example, I tried https://barracuda.com and I could see it in burp.

Then I tested bing.com and I could see it in burp as well. But when I tried to connect to Facebook or Google from the victim machine, I see no traffic in burp at all. There is no single sign of any traffic to Facebook or Google in burp. Not even any error messages. However, I can see the DNS requests made to Facebook and Google in Wireshark. And then some TCP stream exchange follows, which is obviously must be the request response from those two sites. This means the traffic does pass through my Kali Linux machine. Then why am I unable to intercept the traffic in burp?

I tested this issue on both Chrome 66 and Opera browser (both upto date) on my victim machine. Both of them have the same behaviour.

I could see hsts specific errors before importing the burp CA into my victims trusted root. After the import, when I can intercept traffic to bing.com, why can I not intercept the traffic to Facebook or Google? What magic is at work that's stopping me from seeing it in burp?

Any leads would be appreciated. Thanks.

Answer 1

Nevermind. Those websites were using IPv6 over IPv4 and hence due to the encryption of IPv6 I couldn't see the traffic. It turns out that windows has a preference of IPv6 over IPv4 when the network adapter's have a few types of addresses, typical of those assigned by mobile hotspots. (Maybe for security?)

I could see in Wireshark that DNS requests for Facebook and Google were receiving IPv4 as well as IPv6 addresses. But those of Bing and barracuda weren't. And due to the preference of IPv6 over IPv4, IPv6 was used. I force disabled IPv6 support on windows over the adapter in question and as expected things were back to normal.

And it turns out the TCP exchanges that I mentioned are probably something else and not the request responses from Google or Facebook. I realised this by simply running Wireshark on my windows machine, and then abffled at this I did some research and got to know somewhere from Microsoft support about the preference of IPv6 over IPv4.

Hope this helps some pentester somewhere.