search

Ettercap / ettercap

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

ARP MITM only capturing one side of unicast UDP conversation #632

Open johhnybritain opened 9 years ago

johhnybritain commented 9 years ago

I've been using ettercap to capture xbox live traffic to analyse Call Of Duty communications during games, to better understand lag problems. I extended ettercap 0.8.x to add the ability to print a list of active connections along with the min/avg/max ping to all remote connections using a ping lib, and the IP GeoLocation information about remote connections using a whois lib.

My GIT project with the 'enhanced' ettercap is here: https://github.com/johhnybritain/ettercap-with-ping

I am using a simple home network setup with an xbox connected to a broadband router switch and the host PC running ettercap connected to the router via an extension switch. The network traffic being monitored is between the xbox on the local LAN and remote servers on the internet. I am running ettercap on an Ubuntu 12.x machine running in a VMWare VM.

Everything works well, except ettercap only seems to capture egress traffic for some unicast UDP conversations to remote internet hosts, both ingress and egress traffic is being capture for some UDP conversations to remote internet hosts. I have checked with a network tap that the conversations are bi-directional, but only egress traffic is being redirected by the ARP MITM, ingress traffic is being received by the xbox but not being redirected and captured by ettercap.

I have checked that when the ARP MITM is active the MAC address associated with the xbox on the router is the ettercap machine, so I am at a loss as to why the traffic is not being redirected. I have confirmed that I have the same problem with a vanilla build of the latest release of ettercap (0.8.1).

Here is an example command and output from the latest 0.8.1 build (192.168.1.2 = xbox, 192.168.1.1 = broadband router/gateway):

./ettercap -Tq -i eth0 -M arp:remote /192.168.1.2/ /192.168.1.1/ -P autoadd ettercap 0.8.1 copyright 2001-2014 Ettercap Development Team Listening on: eth0 -> 00:0C:29:D1:0E:FD 192.168.1.20/255.255.255.0 fe80::20c:29ff:fed1:efd/64 SSL dissection needs a valid 'redir_command_on' script in the etter.conf file Privileges dropped to UID 0 GID 65534... 33 plugins 42 protocol dissectors 57 ports monitored 19839 mac vendor fingerprint 1766 tcp OS fingerprint 2182 known services Scanning for merged targets (2 hosts)...

Activating autoadd plugin... Connections list: 192.168.1.2:3074 - 157.56.120.207:3544 U idle TX: 1342 RX: 2289 192.168.1.2:3076 - 209.170.124.117:3074 U active TX: 1334 RX: 0 192.168.1.2:3076 - 185.34.104.124:3074 U active TX: 812 RX: 0 192.168.1.2:57352 - 185.34.107.31:3074 T closed TX: 21282 RX: 726 192.168.1.2:3076 - 79.17.0.128:3076 U idle TX: 88290 RX: 0 192.168.1.2:3076 - 191.233.73.107:31004 U active TX: 1010563 RX: 0 192.168.1.2:3076 - 85.137.122.57:3076 U active TX: 5718 RX: 0 192.168.1.2:3076 - 84.97.144.68:3076 U active TX: 5718 RX: 0 192.168.1.2:3076 - 57.237.146.100:3076 U idle TX: 870 RX: 0 192.168.1.2:3076 - 158.234.227.65:3076 U idle TX: 864 RX: 0 192.168.1.2:3076 - 176.198.143.147:3433 U active TX: 5590 RX: 0 192.168.1.2:3076 - 77.60.216.63:3433 U idle TX: 630 RX: 0

I am assuming that the problem is something to do with the Broadband router not handling the ARP poison in the way I would expect and, is somehow keeping the correct MAC address for the xbox. But I thought I would contact you in case this is a problem with ettercap or there are any known issue like this with ettercap, or you could suggest a solution to the problem.

Thanks

LocutusOfBorg commented 9 years ago

would be nice to try the bridge mode in some way... this can help in tracing down the problem, but I'm thinking about some protections on the router GW

koeppea commented 9 years ago

obviously you figured out the issue. Your router doesn't seem to accept the unsolicited ARP replies. You could try to activate the _arp_poisonrequest option instead of the _arp_poisonreply option in etter.conf. You may also try to activate the _arp_poisonsmart option. Maybe you achieve better results with these adjustments. See man etter.conf for more explanation.

However it might be possible that some devices are not possible to be poisoned easily. In that case your only chance is the bridged mode as @LocutusOfBorg mentioned above.