search

Ettercap / ettercap

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

Ettercap DATA.data is empty #1161

Closed esguti closed 2 years ago

esguti commented 2 years ago

I am trying to prepare a test lab with docker. I have 3 machines, one of them sends data from port 502 to the other (Modbus replied). Another machine is sniffing the traffic using ettercap. After unsuccessfully try to find packet data content, I have printed a message when the data field is empty and the response was "Is empty" when a Modbus response arrives.

This is the filter code:

if (tcp.src == 502) {
     msg("Modbus packet");
     if (DATA.data == "") {
            msg("Is empty");
     }
}

The problem is that the packets have data (attached tcpdump.zip capture for Wireshark).

Could you help me to guess why the data is empty?

Regards

LocutusOfBorg commented 2 years ago

what about doing something like:

if (tcp.src == 502) {
     msg("Modbus packet sent");
     log(DATA.data, "./logfile-sent.log");
}

if (tcp.dst == 502) {
     msg("Modbus packet received");
     log(DATA.data, "./logfile-received.log");
}
LocutusOfBorg commented 2 years ago

I don't think you can compare DATA.data with empty string...

LocutusOfBorg commented 2 years ago 
etterfilter test.filter
ettercap -r /tmp/tcpdump.pcap -G -F filter.ef

worked with your pcap example

esguti commented 2 years ago

Thanks you @LocutusOfBorg , I have followed your instructions, created a new filter:

msg("Applying filter");

if (tcp.src == 502) {
     msg("Modbus packet sent");
     log(DATA.data, "/tmp/logfile-sent.log");
}

if (tcp.dst == 502) {
     msg("Modbus packet received");
     log(DATA.data, "/tmp/logfile-received.log");
}

and created a tcpdump file with just 3 modbus packages, but still, the packet sent (which is the one I am interested) is empty:


──(root💀11320dd3a3c3)-[~]
└─# ettercap -r share/tcpdump_only.pcap -T -q -F modbus-attack.ef

ettercap 0.8.3.1 copyright 2001-2020 Ettercap Development Team

Content filters loaded from modbus-attack.ef...
Reading from share/tcpdump_only.pcap
Privileges dropped to EUID 65534 EGID 65534...

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

Starting Unified sniffing...

Applying filter
Modbus packet received
Applying filter
Modbus packet received
Applying filter
Modbus packet sent

Capture file read completely, please exit at your convenience.

End of dump file...

Terminating ettercap...
Lua cleanup complete!
Unified sniffing was stopped.

┌──(root💀11320dd3a3c3)-[~]
└─# cat /tmp/logfile-received.log 

┌──(root💀11320dd3a3c3)-[~]
└─# cat /tmp/logfile-sent.log 
;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�;8#�;8#�2    ;8#�2   ;8#�2
;8#�2
;8#�2
     ;8#�2
          ;8#�2
               ;8#�2
;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�;8#�;8#�2 ;8#�2   ;8#�2
;8#�2
;8#�2
     ;8#�2
          ;8#�2
               ;8#�2
;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�;8#�;8#�2 ;8#�2   ;8#�2
;8#�2
;8#�2
     ;8#�2
          ;8#�2
               ;8#�2
;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�;8#�;8#�2 ;8#�2   ;8#�2
;8#�2
;8#�2
     ;8#�2
          ;8#�2
               ;8#�2
;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2;8#�2
┌──(root💀11320dd3a3c3)-[~]
└─#

Could you check if you can reproduce this scenario?

Thank you so much!

LocutusOfBorg commented 2 years ago

Hello, what do you want to achieve by using cat? modbus is not sending usually ascii data, and you should print binary files with hexdump or so.

I tried this filter:

msg("Applying filter");

if (tcp.src == 502) {
     msg("Modbus packet sent");
     log(DATA.data, "/tmp/logfile-sent.log");
}

if (tcp.dst == 502) {
     msg("Modbus packet received");
     log(DATA.data, "/tmp/logfile-received.log");
}

log(DATA.data, "/tmp/full.log");
hexdump -C /tmp/full.log 
00000000  1b f6 00 00 00 06 00 03  00 02 00 1c 1b f6 00 00  |................|
00000010  00 06 00 03 00 02 00 1c  1b f6 00 00 00 3b 00 03  |.............;..|
00000020  38 03 23 00 1a 00 00 00  00 00 00 00 00 00 00 00  |8.#.............|
00000030  00 00 00 00 00 00 1e 00  00 00 00 00 00 00 00 00  |................|
00000040  05 00 00 00 00 00 00 00  00 00 32 00 00 00 00 00  |..........2.....|
00000050  00 00 00 00 00 00 00 00  00                       |.........|
00000059
hexdump -C /tmp/logfile-received.log 
00000000  1b f6 00 00 00 06 00 03  00 02 00 1c 1b f6 00 00  |................|
00000010  00 06 00 03 00 02 00 1c                           |........|
00000018
hexdump -C /tmp/logfile-sent.log 
00000000  1b f6 00 00 00 3b 00 03  38 03 23 00 1a 00 00 00  |.....;..8.#.....|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 1e 00  |................|
00000020  00 00 00 00 00 00 00 00  05 00 00 00 00 00 00 00  |................|
00000030  00 00 32 00 00 00 00 00  00 00 00 00 00 00 00 00  |..2.............|
*
00000041
ls -l /tmp/full.log /tmp/logfile-*
-rw------- 1 user user 89 gen 21 09:31 /tmp/full.log
-rw------- 1 user user 24 gen 21 09:31 /tmp/logfile-received.log
-rw------- 1 user user 65 gen 21 09:31 /tmp/logfile-sent.log

24+65=89.

esguti commented 2 years ago

Sorry, I didn't know about hexdump, I just wanted to show you that the file was empty, but I was wrong.

I made more tests and I found that the problem occurs only when I do arp spoofing, independently of the filter. 

┌──(root💀a35a8da46daf)-[~]
└─# ettercap -T -i eth0 -M arp /172.16.238.10// /172.16.238.11//

ettercap 0.8.3.1 copyright 2001-2020 Ettercap Development Team

Listening on:
  eth0 -> 8A:CA:58:B9:E9:30
      172.16.238.12/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
28230 mac vendor fingerprint
1766 tcp OS fingerprint
2182 known services
Lua: no scripts were specified, not starting up!

Scanning for merged targets (2 hosts)...

* |==================================================>| 100.00 %

3 hosts added to the hosts list...

ARP poisoning victims:

 GROUP 1 : 172.16.238.10 8A:CA:58:B9:E9:10

 GROUP 2 : 172.16.238.11 8A:CA:58:B9:E9:20
Starting Unified sniffing...

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

Fri Jan 21 09:48:30 2022 [502061]
TCP  172.16.238.11:40086 --> 172.16.238.10:502 | AP (12)
.-..........

Fri Jan 21 09:48:30 2022 [707322]
TCP  172.16.238.11:40086 --> 172.16.238.10:502 | AP (12)
.-..........

Fri Jan 21 09:48:30 2022 [915352]
TCP  172.16.238.11:40086 --> 172.16.238.10:502 | AP (12)
.-..........

Fri Jan 21 09:48:31 2022 [343379]
TCP  172.16.238.11:40086 --> 172.16.238.10:502 | AP (12)
.-..........

Fri Jan 21 09:48:32 2022 [175372]
TCP  172.16.238.11:40086 --> 172.16.238.10:502 | AP (12)
.-..........

Fri Jan 21 09:48:33 2022 [839381]
TCP  172.16.238.11:40086 --> 172.16.238.10:502 | AP (12)
.-..........

Fri Jan 21 09:48:37 2022 [231419]
TCP  172.16.238.11:40086 --> 172.16.238.10:502 | AP (12)
.-..........

Fri Jan 21 09:48:43 2022 [887419]
TCP  172.16.238.11:40086 --> 172.16.238.10:502 | AP (12)
.-..........

Fri Jan 21 09:48:44 2022 [655358]
TCP  172.16.238.10:502 --> 172.16.238.11:40086 | A (0)

Fri Jan 21 09:48:57 2022 [199340]
TCP  172.16.238.11:40086 --> 172.16.238.10:502 | AP (12)
.-..........Closing text interface...

Terminating ettercap...
Lua cleanup complete!
ARP poisoner deactivated.
RE-ARPing the victims...
Unified sniffing was stopped.

and this is the capture with tcpdump: dumpfile_spoof_without_filter.zip. If you filter by tcp.port==502, you will see that the response Data is missing.

Could it be because I am using docker containers? ettercap is running in a privileged container. I will test with virtualmachines

esguti commented 2 years ago

I can tell that docker is not the problem. I have checked out the arp table on the victims and the MAC addresses correspond to the attacker, so arp spoofing is working well. I have also checked this example and it works fine.

Analyzing the TCP packet with "tcp.srcport == 502" filter, I can see that the retransmission contains no data. In the image below you can see that the modbus packet arrived perfectly from the source (MAC: 8a:ca:58:b9:e9:10) to the attacker (MAC: 8a:ca:58:b9:e9:12) image

But the retransmission from the attacker (MAC: 8a:ca:58:b9:e9:12) to the target (MAC: 8a:ca:58:b9:e9:11) has no data: image

koeppea commented 2 years ago

hi @esguti I'm afraid you're getting distracted by the way Wireshark is displaying the packet details. In your first screenshot above, you see in the packets summary that both packets are 131 bytes long in total. In the packet details pane, you see that TCP protocol has a length of 65. So TCP has 65 bytes of payload. Wireshark dissects it as Modbus/TCP - Modbus.

In the screenshot of the retransmitted packet (packet details), you can see that TCP protocol also contains 65 bytes of data. Wireshark just doesn't desects it, because its a re-transmission and the originial payload dissection happed in the original packet.

Compare the packets using the bytes view of Wireshark. The TCP payload bytes are identical. As this is the purpose of a retransmission in TCP.

In Ettercap, DATA.data refers to the TCP payload. If a TCP packet is really empty, like a pure ACK, you can only determine this by evaluating the ìp.len field. TCP only codes the header length as 4-bits into the flags bytes, but has no direct indication about how much of payload data it's containing. IP protocol demoninates the total length as a direct value, including the IP header, TCP header (which can be variable) and the TCP payload.

esguti commented 2 years ago

Hi, you are totally right @koeppea. I finally found the error, it was not Ettercap. I was doing 1 request per second and I suppose it was too much for processing, after changing to 1rqst every 5 seconds it's all right.

Thank you both @LocutusOfBorg and @koeppea for your support, I have learned a lot, and sorry for taking your time with this problem :)

LocutusOfBorg commented 2 years ago

Thanks @esguti ! I'm happy to have to work with modbus protocol from time to time, I really find it entertaining :)