ARP poisoning not working

[rosseljost]

ettercap version: 0.8.2
Ubuntu version: 18.04

setup:
network hub on which the following devices are connected:

• Philips Hue Hub (supporting TLS1.2)
• An WiFi Access Point (+DHCP) on which an Android 9 Smartphone (Oneplus 6) is connected
• the Ubuntu machine

Using Wireshark I can sniff all packages via my Ethernet port (enxa0cec8066e9e), everything works as expected.
Now I am trying to MitM the TLS Connecting of the Philips Hue Hub and the Smartphone. To do so I manually installed a certificate in the Hue App running on the Smartphone -- originally there was the Hue Hub certificate installed.
So everything that is left to do is run ettercap as a MitM with my new certificate and capture the traffic in a .pcap file. Here is what I've tried (linebreaks just for readability):

sudo ettercap 
-T
-M ARP 00:17:88:B0:03:92/// 64:A2:F9:29:66:FA/// 
--certificate certificates/selfmade-256.pem 
--private-key certificates/key-256.pem 
--iface enxa0cec8066e9e 
-w ettercap01.pcap

I get the warning:

SSL dissection needs a valid 'redir_command_on' script in the etter.conf file
Ettercap might not work correctly. /proc/sys/net/ipv6/conf/all/use_tempaddr is not set to 0.
Ettercap might not work correctly. /proc/sys/net/ipv6/conf/enxa0cec8066e9e/use_tempaddr is not set to 0.
Privileges dropped to EUID 65534 EGID 65534...

and the error:

FATAL: ARP poisoning needs a non empty hosts list.

I really appreciate any help on why this doesn't work and what the warning means.

[koeppea]

Hi @fhred
So SSL interception really needs the correct redir_command_{on,off} uncommented in the etter.conf. In your case the iptables version in the Linux section.
Not to forget the EUID set to 0 to keep the root permission

The second warning lets assume you're located in a dual-stack envrionment running IPv6 with IPv4 in parallel. The warning itself is just a experience from the past. So you'd set this to 0:

echo 0 > /proc/sys/net/ipv6/conf/{enxa0cec8066e9e,all}/use_tempaddr

Since ARP acts between IP and Ethernet, poisoning an ARP cache relies on IP information given that it should poison. Since you're apparently in IPv6 also active environment, you'd consider doing similarly ND poisoning because ARP is limited to IPv4 only. And also the ip6tables commands to redirect IPv6 SSL traffic accordingly.
Moreover, ARP and ND poisoning should get passed the remote keyword, to allow sniffing for remote destinations even if the actual poisoned target (gw) is local. So -M arp:remote. Of course only if your scenario requires this.

[rosseljost]

Hi @koeppea

Thanks for you help. After doing these steps it worked.

So SSL interception really needs the correct redir_command_{on,off} uncommented in the etter.conf. In your case the iptables version in the Linux section.
Not to forget the EUID set to 0 to keep the root permission

The IPv6 part was not needed, the network only supports IPv4, so explicitly giving ettercap the IPv4 addresses was enough.

sudo ettercap 
-T
-M ARP:remote 00:17:88:B0:03:92/192.168.1.100// 64:A2:F9:29:66:FA/192.168.1.101// 
--certificate certificates/selfmade-256.pem 
--private-key certificates/key-256.pem 
--iface enxa0cec8066e9e 
-w ettercap01.pcap

While running ettercap -T I get messages like

Mon Nov 19 10:51:45 2018 [35288]
TCP  192.168.1.100:80 --> 192.168.1.101:44638 | SA (0)

where can I lookup what these letters at the end stand for? Stuff like: S(...), SA(...), FA(...), where the number brackets seems to be a message size in bytes.
In the .pcap file I can see, that the ARP poisoning works and also, that TLS connections to the Smartphone and to the Hub are established.
So are messages that are forwarded by the MitM displayed as TLS or as TCP? If TCP is the case, how can I distinguish between 'normal' TCP messages and decrypted ones? Or are the decrypted messages not displayed in the console by default?

[koeppea]

The verbose output (can be toggled by hitting ) shows the relvant TCP related information. The letters stand for the various flags like S for SYN, A for ACK and F for FIN.

Reg. dissecting the packet capture file, it's heavily depdent on the network analysis software. E.g. Wireshark shows pure Bytes In Flight segments as TCP. Only if a set of segments compose a complete TLS message, Wireshark shows these finalizing packets as a TLS packet.

However, you don't see the decrypted packets content though. Ettercap currently dumps only the raw packet arriving. This isn't yet supported by Ettercap. You can only inpect the content by detailing the connection in the connections list. For that, the use of the graphical interface is recommended.

Cloing the issue since the actual issue is fixed.