PART 1: Generic explanation, unnecessary to read if you have read the question.
The first (how does the packet arrive at the attacker):
Victim sends a packet with source IP '192.168.1.3' and source MAC
'00:00:00:00:00:03' to destination IP 'DEST' and destination MAC
'00:00:00:00:00:01'. Where 'DEST' is some external IP like '47.32.1.6'
The router receives the packet and because the MAC is pointing to me
(as the attacker) it forwards the packet to my interface.
The victim sends a packet with source IP '192.168.1.3' and sourced MAC '00:00:00:00:00:03' to destination IP '47.32.1.6'. The victim cannot find a direct route to this address (as it is not in his subnet), so it sends the packet via the default route, to '192.168.1.1' (i.e. to the default gateway, the router in this case). However, as we are on ethernet, the victim needs a MAC address to send the packet. You mention that the router has MAC address '00:00:00:00:00:00', but the attacker has poisoned the victim's ARP table. Instead of the entry
192.168.1.1 00:00:00:00:00:00
the victim has the following entry in his ARP table:
192.168.1.1 00:00:00:00:00:01
(You can check this by opening a command line on the victim's PC, and running the command 'arp -a' before and after you started Ettercap).
This means that, whenever the victim tries to send a packet to the router OR to the external network, this packet will arrive at the attacker, until you 'RE-ARP' the victim.
The second (how does the packet arrive at its real destination):
Now Ettercap gets the packet and recognizes the source IP as victim's IP (which is '192.168.1.3') and the destination IP as the router (second victim), then sends this packet to forward the packet to real host and allow streaming:
Before the poisoning starts, the attacker makes sure his ARP table contains the correct entries, like so:
192.168.1.1 00:00:00:00:00:00 (the router)
192.168.1.3 00:00:00:00:00:02 (the victim)
Now, in the first section, we stopped at the point where the external packet arrived at the attacker's PC, but of course, we need to make sure the packet reaches its 'real' destination. Otherwise, the victim would never get a real response, and would thus notice it fairly quickly that something's off. Therefore, the attacker wishes to forward the packet to its real destination: the default gateway (the router). This is possible, as the attacker knows the real MAC address of the router. It actually receives the following packet from the victim:
Source IP: 192.168.1.3
Source MAC: 00:00:00:00:00:03
Destination IP: 47.32.1.6
Destination MAC: 00:00:00:00:00:01
The fact that the destination IP is translated to the MAC address of the attacker, is because the victim will look up the destination IP in its routing table (route print), and it finds that it should send this packet to the default gateway. It therefore sends out an ARP request (or looks in his ARP table, arp -a), and notices that the MAC address the packet should be sent to is '00:00:00:00:00:01'
What's important here is the fact that the attacker sees that this is a packet that is actually not intended for him. A packet that would have been intended for him would look like this:
Source IP: 192.168.1.3
Source MAC: 00:00:00:00:00:03
Destination IP: 192.168.1.2
Destination MAC: 00:00:00:00:00:01
So, whenever the attacker receives a packet, he will check the source and destination IP, and forward it using his unpoisoned ARP-table, in this case to '00:00:00:00:00:00' (the router).
PART 2: Summary of the question asked
At first, the question was not fully clear to me. However, after CS explained it more carefully in chat, the question comes down to this:
In a set-up, where Ettercap is active AND a custom application listening on port 8080 is actively forwarding traffic (to the victim), and where port forwarding is active to redirect traffic coming in on port 80 to port 8080 (the custom app), why is it that the these packets (the one originally intended for port 80) arrive at the victim only once?
One might think that the following would happen:
- Packet comes in on port 80, actually intended for the victim, but redirected to the attacker because of an ARP poisoning attack
- Iptables redirects this packet to port 8080
- Ettercap forwards the packet to the victim
- The custom application, which is explicitly built for forwarding packets, also forwards the packet to the victim
However, the victim receives the packet only once. Why?
PART 3: The final answer
Ettercap will only forward traffic which has the following characteristics:
- the dest mac address of the packet is the same of the mac address of the attacker
- the dest ip is not the same as the ip address of the attacker
Now, the problem is that, by using the iptables REDIRECT command, the following happens:
- the destination port is changed (from 80 to 8080 in this particular case)
- the destination IP is changed to the main IP address of the device on which iptables is running.
- as this is a PREROUTING rule, the above happens before the packet reaches Ettercap
It is the 'destination IP change' that answers the question why the packet is not forwarded twice. Imagine the following packet, intended for an external web server, coming from the victim:
Source IP: 192.168.1.3
Source MAC: 00:00:00:00:00:03
Destination IP: 47.32.1.6:80
Destination MAC: 00:00:00:00:00:01
If this packet were to arrive at Ettercap, the forwarding condition would have been fulfilled: The destination MAC of the packet is the attacker's, but the destination IP is not.
Now, this packet does not arrive in that form, the iptables REDIRECT command transforms it to the following:
Source IP: 192.168.1.3
Source MAC: 00:00:00:00:00:03
Destination IP: 192.168.1.2:8080
Destination MAC: 00:00:00:00:00:01
It does so, because 192.168.1.2 is the main IP address of the device on which the redirect command takes place. Thus, this packet will be ignored by Ettercap.
PART 4: Final insight
Now, the above is actually the same that happens in case you enable SSL dissection. To enable SSL dissection, the following lines need to be uncommented in etter.conf:
redir_command_on = "iptables -t nat -A PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"
redir_command_off = "iptables -t nat -D PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"
As you may notice, this is almost exactly the same command as the iptables command mentioned in the question. Therefore, the same applies: ettercap does NOT forward packets coming in on port 443. What happens is the following:
- Traffic from the victim comes in, that is supposed to go to a https server
- Because it is redirected by iptables, ettercap will not forward it anymore (as the destination IP is changed). This means all SSL traffic stays on the attacker's pc.
- Ettercap then creates a fake server, with a fake certificate. It starts communicating with the real ssl server to provide HTML/JS, but the client talks DIRECTLY to ettercap. Packets are not forwarded anymore.
This is the same as in the case explained in the question, except for the fact that the SSL dissector does NOT forward traffic, whereas the application created by the TS still does.