Trying to perform MiTM on an IoT device that cannot set gateway or proxy

Question

I am currently trying to perform MiTM attack on a target IoT device (192.168.0.10) which does not provide any means to manually setup network related parameters.

The attacker is a VM hosted on my PC, using bridge mode to get its IP address (192.168.0.3).

I setup burpsuite on the VM and have it listen to 0.0.0.0:8080, with invisible proxying enabled. Then, I set iptables -t nat -I PREROUTING -p tcp -s 192.168.0.10 -j DNAT --to-destination 192.168.0.3:8080 on the Wi-Fi router (192.168.0.1). This should send all tcp traffic from victim to my attacker VM.

Here's the problem I met:

1. The victim RST its tcp connection right after attacker responded SYN, ACK during tcp handshake. Not even getting to the stage of certificate validation.

2. From a pcap captured on attacker VM, it seems while victim is trying to contact a WAN IP address (say, 8.8.8.8), it got tcp handshake response from attacker VM (192.168.0.3). So the routers seems to not be masquerading reponse IP address and this may be what's making victim to RST the connection.
   

I'm not sure if I'm seeing this behavior because I'm capturing packets on a bridge network, and the victim actually sees response from 8.8.8.8, or it actually sees response from attacker.

The way I'm performing this MiTM test is probably less then ideal. I have very little experience in networking, so please let me know what is the proper way to set things up!

Answer 1

So the routers seems to not be masquerading reponse IP address and this may be what's making victim to RST the connection.

Your router doesn't have the opportunity to do so, because the attacker VM sees that the peer's IP address is local (in the same subnet) and will reply to it directly, bypassing the router.

(This is the exact same situation as the typical "NAT hairpin" problems that come from trying to use port-forwarding from the inside of the same LAN.)

Think of your "Wi-Fi router" as two (three) separate devices: the Wi-Fi access point (and the wired LAN ports) are an Ethernet-layer bridge, with the router's CPU being just another device connected to that bridge and only receiving traffic that's directed to the router's MAC address specifically – whereas if attacker VM sends a packet towards the MAC address of victim, that is directly switched to the appropriate Ethernet port and bypasses the "router".

To make your DNAT trick work correctly, you need to force the attacker VM to talk to victim IP address through the router, in one of the following ways:

• On the attacker VM add a static /32 route for the victim's IP address, specifying your router as the gateway. This will automatically have priority over the built-in /24 "local subnet" route. But you should also disable the "Accept redirects" setting in the VM (as the router will keep suggesting a more direct path).

• Or, on the router add a SNAT or MASQUERADE rule that matches the same packets as your DNAT rule, but rewrites their source IP address, so that the attacker VM thinks all "victim" packets come from router (and will therefore respond to router as well).

• Or, split your network in two – place "victim" in one subnet and "attacker" in another. This will make DNAT work, as communications between subnets necessarily go through a router.