4

Suppose these assumptions:

Router IP address: 192.168.1.1

Router MAC address: 00:00:00:00:00:00

My IP address: 192.168.1.2

My MAC address: 00:00:00:00:00:01

Victim IP address: 192.168.1.3

Victim MAC address: 00:00:00:00:00:03

Now if I perform an ARP poisoning attack using Ettercap between router and victim, if the victim wants to send a packet to external host this is what would happen:

Victim sends a packet with (according to what wireshark shows):

Source IP : 192.168.1.3

Source MAC: 00:00:00:00:00:03

Destination: IP 'DEST'. Where 'DEST' is some external IP like '47.32.1.6'

Destination MAC: 00:00:00:00:00:01

Because the packet should be delivered to EXTERNAL host, it should be first delivered to the router whose MAC address from victim's point of view is '00:00:00:00:00:01'

The router receives this packet and because the MAC is pointing to me (as the attacker) it forwards the packet to my interface.

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:

Source IP: 192.168.1.3
Source MAC: 00:00:00:00:00:01
Destination IP: DEST
Destination MAC: 00:00:00:00:00:00

This process takes place for every packet receiving from victim to Ettercap, but if I use port forwarding by IPtables rules, then it seems that the received packet to my machine from victim should be sent to router twice, because:

  1. Ettercap receives the packet and as far as it is from the victim, Ettercap forwards it to router.

  2. The OS delivers the packet to local running app which is listening on predefined port. For example if I use the command below:

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

then any packet targeting port 80 is delivered to local app listening on 8080 and then the app can send the packet to external host. (For example if it's a proxy)

But surprisingly this won't happen. In fact what does happen is only step 2. The packet is delivered to the local app and it processes ahead.

I think this is because OS changes the "destination IP address" of receiving packet to our interface IP address, so when Ettercap catches the packet and detects that the destination IP is the address of our own machine, it ignores the packet. But Wireshark shows the correct IP address, not the changed one. Can some experts please explain what exactly happens here?

8

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.

  • You deserve more votes – Purefan Aug 12 '15 at 7:54
  • 1
    Thanks but first you didn't answer the main issue. Second I checked all packets mentioned by wireshark and they are exactly as I said. When victim wants to communicate with external host the ip header contains the IP Address of external host as "destination IP" not the IP address of default router. Other wise how the router would be able to forward the packet to external host when doesn't know the destination ip? But of course MAC Address is router's as the packet should first be delivered to router to be forwarded out. But up to now I still don't know why the packet is not redirected twice. – CS. Aug 12 '15 at 8:35
  • Well, I've updated my answer. The destination IP does not change indeed, but it still is linked to the MAC address of the default gateway, which is poisoned by the attacker. Step 1: check routing table, step 2: send to default gateway. Please check serverfault.com/a/419142 for more details, as it is more a networking question you have now. And second, what exactly is your main issue then? – Michael Aug 12 '15 at 8:56
  • As you edited your answer then the first part of it (as you called my first incorrect reasoning) is not in contrary to what I said. Even the second part is what I said. Maybe I couldn't clarify what I want. You described how ARP poisoning works as I already know about it. But please read the part of my question which considers the scenario in which we use port forward. I expect the packet to be forwarded twice. But it isn't – CS. Aug 12 '15 at 9:59
  • Because this is wrong: "The router receives this packet and because the MAC is pointing to me (as the attacker) it forwards the packet to my interface." It does NOT receive the packet here, it only receives it after the attacker sends it to the router, not when the victim sends it to the router.. If you follow my explanation, you will see that I do not talk about forwarding twice, that's why it is the answer to your question. – Michael Aug 12 '15 at 10:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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