search

Ettercap / ettercap

Ettercap Project
http://www.ettercap-project.org
GNU General Public License v2.0
2.37k stars 493 forks source link

Ettercap MitM attack leads to TCP Re transmission #1145

Open AlirezaDehlaghi opened 3 years ago

AlirezaDehlaghi commented 3 years ago

Hi

I have docker container simulation which have several nodes as follow Node_1 (192.168.0.11) ----------docker Bridge network --------- Node_2 (192.168.0.22) The Node_3 (192.168.0.41) is attacker that run => ettercap -Tqi eth0 -M arp /192.168.0.22// /192.168.0.11//

Problem is that when I Run the attack script, the connection between node 1 and 2 will be damaged.

I tried to sniff packets with wireshark. (the real filter for wireshark is (ip.src == 192.168.0.22) || (ip.dst == 192.168.0.22)) Screenshot from 2021-09-29 02-49-50

I found out that running attack script leads to TCP retransmission error, as it is shown in the wire shark image.

AlirezaDehlaghi commented 3 years ago

To complete My question: In the above picture I tried to send a packet from Node2 (192.168.0.22 : 02:42:c0:a8:00:16) to node1 (192.168.0.11 : 02:42:c0:a8:00:0b)

When I send this packet I can see two packets in wire shark which is reasonable: from 02:42:c0:a8:00:16 -> 02:42:c0:a8:00:29 (it is attacker MAC) from 02:42:c0:a8:00:29-> 02:42:c0:a8:00:0b but when the Node2 does not replay, Node1 tries to retransmit packet again and again.

The Problem is that my packet is TCP and the destination should reply it. It reply in normal situation, but when I am running arp with ettercap it does not replay.

****Command to attack: **** ttercap -Tqi eth0 -w ettercap-packets.pcap -M arp /192.168.0.11// /192.168.0.22//

****Ettercap footprint**** root@6e371a87b8f6:/src/attacks# ./mitm.sh

ettercap 0.8.3 copyright 2001-2019 Ettercap Development Team

Listening on: eth0 -> 02:42:C0:A8:00:29 192.168.0.41/255.255.255.0

SSL dissection needs a valid 'redir_command_on' script in the etter.conf file Privileges dropped to EUID 65534 EGID 65534...

34 plugins 42 protocol dissectors 57 ports monitored 24609 mac vendor fingerprint 1766 tcp OS fingerprint 2182 known services Lua: no scripts were specified, not starting up!

Scanning for merged targets (2 hosts)...

2 hosts added to the hosts list...

ARP poisoning victims:

GROUP 1 : 192.168.0.11 02:42:C0:A8:00:0B

GROUP 2 : 192.168.0.22 02:42:C0:A8:00:16 Starting Unified sniffing...

Text only Interface activated... Hit 'h' for inline help

AlirezaDehlaghi commented 3 years ago

Update: The only solution that I found is enabling ip forwarding with (sysctl -w net.ipv4.ip_forward=1) which based on your advise in related issue #1121 it is not a correct solution. (I found that extra packets will be seen if I enable ip_forward).

So what is the correct solution.

koeppea commented 3 years ago

Correct that is not a correct solution. Can you please provide the packets.pcap file?

AlirezaDehlaghi commented 3 years ago

This is the packets.pcap ettercap-packets.zip file.

koeppea commented 3 years ago

From the packet capture everything looks fine. However it appears that between the attacker and the victim, there is something that either detects the ARP poisoning (Some WiFi access points "optimize" on ARP level) or got confused about the "changed" situation..

Please try modifying the following settings in etter.conf:

arp_poison_smart = 1
arp_poison_reply = 0
arp_poison_request = 1
AlirezaDehlaghi commented 3 years ago

This solution did not worked. This ettercap-packets.zip is the logs.

At I mentioned before, I am working in docker container and I used bridged network to connect the containers. I wonder why the destination does not answer the attacker. (Do you change the CRC codes of the packets too?)

koeppea commented 3 years ago

Of course CRC checksum is updated after Ettercap has processed the packet. Let me inspect the new packet capture...

koeppea commented 3 years ago

I checked the updated packet capture. Target 2 (02:42:c0:a8:00:16 192.168.0.22) seems to be successfully poisoned. But again not Target 1 (02:42:c0:a8:00:0b 192.168.0.11).

Target 2 sends a SYN request for reaching Target 1 via the Ettercap. Ettercap relays that SYN request towards the Attacker w/o any other modification other than the MAC address. However, either the packet never reaches Target 1 or Target 1 filters on port 502 which I don't really think.

So I don't know exactly what how the Docker construct influences the whole setup. Can you try to connect to this port from the Attacker via telnet or nc or netcat: $ netcat -v 192.168.0.11 502

AlirezaDehlaghi commented 3 years ago

Hi again. Yes, I tried $ netcat -v 192.168.0.11 502 I can connect from attacker node -> (Connection to 192.168.0.11 502 port [tcp/*] succeeded!) and still cannot connect to 192.168.0.11 502 from Target 2 (02:42:c0:a8:00:16 192.168.0.22) I have another guess: I noticed that you don't change the time stamp, and the time-to-live for the packets are 60 . Is it possible that attacker forwarding process takes more time than 60 ms so leads to packet timeout?

koeppea commented 3 years ago

What do you mean with time-to-live?

The TTL field in the IP header?

AlirezaDehlaghi commented 3 years ago

Yes, but my idea is not valid. Sorry, it is my mistake. TTL is based on seconds. So Just skip my guess. I have no idea what else I should check. At least recreation of the problem is so easy. (just three docker containers based on Ubuntu 20.04) Did you ever try ettercap on docker?

AlirezaDehlaghi commented 3 years ago

I also had another experiment to remove the effect of the docker bridged network.

I Tried With GNS3 Network Simulator with two different switches. 1) its default switch and 2) Westermo switch. Exactly the same issue!

AlirezaDehlaghi commented 3 years ago

@koeppea any update? did you test the issue? any possible solution?

koeppea commented 3 years ago

I don't use GNS3 anymore. Is it possible to get a setup up with a real switch?