Modbus – Angriffe im lokalen Netzwerk
Firmennetzwerke sind mittlerweile sehr gut gegen direkte Angriffe aus dem Internet geschützt. Eine Perimeter Firewall an der Netzwerkgrenze zum Internet blockiert erfolgreich Verbindungsversuche. Die Angreifer haben schon bald auf diese Situation reagiert und ihre Methoden verändert. Eine Perimeter Firewall alleine reicht schon lange nicht mehr für einen erfolgreichen Schutz aus. Angriffe starten im ersten Schritt meist von innen, um damit einen stabilen Zugang in das Netzwerk zu ermöglichen. Für den Initialzugriff stehen den Angreifern zahlreiche Möglichkeiten zur Verfügung. Sehr beliebt sind Phishing E-Mails mit nicht vertrauenswürdigen Links oder Office-Dokumente mit infizierten Makros im Anhang, USB-Devices mit Schadsoftware oder Einsatz von veralteter, nicht gepatchter Software kann zu einem ersten Zugang in die Infrastruktur dienen. Nach dieser Phase erfolgt die Kommunikation aus dem Netzwerk zurück zum Angreifer. Auch hier müssen Firewalls sauber konfiguriert sein, um auch den ausgehenden Datenverkehr zu filtern. Datenkanäle via ICMP- oder DNS-Tunneling sind oft einfach möglich und müssen explizit bei der Firewall-Konfiguration betrachtet werden.
Die Betreiber der IT-Infrastruktur sollten bei den Sicherheitsbetrachtungen stets davon ausgehen, dass sich ein möglicher Angreifer bereits im Netzwerk befindet. Nach dem initialen Zugriff und der Herstellung einer stabilen Verbindung (Rückkanal) zum Angreifer hängen die nächsten Schritte stark von der internen Struktur und den implementierten Schutzmaßnahmen des Netzwerkes ab. Durch fehlende Netzwerk-Segmentierung sind Produktionsnetzwerke oft direkt aus dem Office-Bereich erreichbar.
Die folgenden Betrachtungen gehen bereits davon aus, dass ein Angreifer Netzwerkzugriff zu einem Produktionsnetzwerk hat.
Modbus
Das Modbus-Protokoll ist ein über 40 Jahre altes Kommunikationsprotokoll aus dem Bereich der Automatisierungstechnik. Zu Beginn wurde das Protokoll rein auf seriellen Datenverbindungen (RS-232 / RS-485) verwendet. Mit der Einführung von Modbus over TCP im Jahr 2007 konnten die Mechanismen nun auch in klassischen Netzwerken verwendet werden. Modbus over TCP verwendet per Default das TCP-Port 502.
Modbus dient zur Übertragung von Konfigurations- und Messwerten bis hin zur Ansteuerung von Aktoren über Schaltausgängen auf Steuerungen (SPS). Durch die lange Lebensdauer von Industrieanlagen ist das Protokoll nach wie vor weit verbreitet.
Eine Suche mit der Suchmaschine SHODAN [1] nach Systemen mit offenem Port 502 liefert die erschreckende Anzahl von mehr als 38.000 Geräten, die direkt aus dem Internet erreichbar sind.
Das Modbus-Protokoll ist sehr einfach aufgebaut und besteht aus wenigen Datenfeldern:
| Transaction ID: | 2 Bytes Request ID |
| Protocol ID: | 2 Bytes 00 00 |
| Length: | 2 Bytes Länge |
| Unit ID: | 1 Byte Device ID |
| Fcode: | 1 Byte Function Code (Read/ Write Coil/ Register) |
| Data: | Daten |
Modbus wird unverschlüsselt im Klartext übertragen und enthält keinerlei Mechanismen zur Authentifizierung eines Kommunikationspartners. Im Jahr 2018 wurde eine auf TLS basierende, sichere Version von Modbus veröffentlicht. Die folgenden Betrachtungen basieren auf der unverschlüsselten Variante des Protokolls.
Szenarien
Abb. 2 zeigt die Infrastruktur für die nachfolgenden Betrachtungen.
Das Szenario besteht aus einer Modbus-enabled SPS (192.168.0.2), an der einige Aktoren angeschlossen sind (M), einem Layer-2 Switch und einer Engineering Station (192.168.0.20). Der Angreifer hat einmal direkten (Layer-2) Netzwerkzugang (192.168.0.30) und einmal Zugang über eine Firewall aus einem externen Netzwerksegment. Ein Aktor ist an der SPS angeschlossen, der Ausgang wird allerdings nicht von dem SPS-Programm benutzt. Der Engineer bedient die SPS über eine Engineering-Software, zur vereinfachten Darstellung wird ein Modbus-Client aus dem Metasploit-Framework auf KALI-Linux verwendet.
Im ersten Schritt wird der Engineer den Aktuator mithilfe des Modbus Clients ein- und ausschalten.
root@engineer:~# ifconfig eth0: inet 192.168.0.20 netmask 255.255.255.0 root@engineer:~# ping 192.168.0.2 PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data. 64 bytes from 192.168.0.2: icmp_seq=1 ttl=30 time=1.42 ms 64 bytes from 192.168.0.2: icmp_seq=2 ttl=30 time=0.799 ms root@engineer:~# msfconsole msf5 > use auxiliary/scanner/scada/modbusclient msf5 auxiliary(scanner/scada/modbusclient) > set RHOSTS 192.168.0.2 msf5 auxiliary(scanner/scada/modbusclient) > set ACTION WRITE_COILS msf5 auxiliary(scanner/scada/modbusclient) > set DATA_ADDRESS 0 msf5 auxiliary(scanner/scada/modbusclient) > set DATA_COILS 11111111 msf5 auxiliary(scanner/scada/modbusclient) > run [*] Running module against 192.168.0.2 [*] 192.168.0.2:502 - Sending WRITE COILS...
Damit werden alle Ausgänge, die nicht aktuell vom SPS-Programm bedient werden, eingeschaltet – Der Motor läuft. Um den Motor wieder auszuschalten, setzten wir die DATA_COILS wieder auf 0.
msf5 auxiliary(scanner/scada/modbusclient) > set DATA_COILS 00000000 msf5 auxiliary(scanner/scada/modbusclient) > run [*] Running module against 192.168.0.2 [*] 192.168.0.2:502 - Sending WRITE COILS...
Das folgende Bild zeigt den Netzwerkverkehr aufgezeichnet mit den Netzwerk-Sniffer Wireshark [2].
Die folgenden Schritte erfolgen von einem Angreifer mit Netzwerkzugang auf Basis Layer-2, d. h. der Angreifer befindet sich im selben Netzwerksegment. Der Angreifer verwendet ebenfalls KALI-Linux.
root@attacker:~# ifconfig
eth0: inet 192.168.0.30
netmask 255.255.255.0 Mittels netdiscover erfolgt nun ein ARP-Scan des Netzwerks, die IP-Adresse der Steuerung (192.168.0.2) kann einfach gefunden werden.
root@attacker:~# netdiscover
Currently scanning: 192.168.0.0/16 | Screen View:Unique Hosts
13 Captured ARP Req/Rep packets, from 13 hosts. Total size: 780
________________________________________________________________
IP At MAC Address Count Len MAC Vendor
----------------------------------------------------------------
192.168.0.2 28:63:36:99:35:85 1 60 Siemens AG
192.168.0.10 00:0c:29:8e:36:88 1 60 VMware, Inc.
192.168.0.20 00:0c:29:90:7f:66 1 60 VMware, Inc. Die Steuerung antwortet auch auf eine Anfrage via ping.
root@attacker:~# ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
64 bytes from 192.168.0.2: icmp_seq=1 ttl=30 time=1.19 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=30 time=0.578 msEin Portscan via nmap [3] identifiziert das Modbus-Protokoll auf TCP-Port 502.
root@attacker:~# nmap -n 192.168.0.2 -p 102, 502 Starting Nmap 7.80 ( nmap.org ) at 2021-06-17 09:37 EST Nmap scan report for 192.168.0.2 Host is up (0.0014s latency). PORT STATE SERVICE 102/tcp open iso-tsap 502/tcp open mbap MAC Address: 28:63:36:99:35:85 (Siemens AG)
Das Metasploit Framework enthält auch ein Auxiliary-Modul zur Identifikation des Modbus-Services:
root@attacker:~# msfconsole msf5 > search modbus Matching Modules ================ ... auxiliary/scanner/scada/modbusclient Modbus Client Utility auxiliary/scanner/scada/modbusdetect Modbus Version Scanner ... msf5 > use auxiliary/scanner/scada/modbusdetect msf5 auxiliary(scanner/scada/modbusdetect) > show options Module options (auxiliary/scanner/scada/modbusdetect): Name Current Setting Required Description ---- --------------- -------- ----------- RHOSTS yes The target host(s), range RPORT 502 yes The target port (TCP) THREADS 1 yes The number of concurrent TIMEOUT 10 yes Timeout for the network probe UNIT_ID 1 yes ModBus Unit Identifier, 1..255, most often 1 msf5 auxiliary(scanner/scada/modbusdetect) > set RHOSTS 192.168.0.2 msf5 auxiliary(scanner/scada/modbusdetect) > run [+] 192.168.0.2:502 - 192.168.0.2:502 - MODBUS - received correct MODBUS/TCP header (unit-ID: 1)
Der Angreifer kann nun analog zum Engineer Modbus-Kommandos zur Steuerung senden und damit eine Schalthandlung auslösen.
msf5 > use auxiliary/scanner/scada/modbusclient msf5 auxiliary(scanner/scada/modbusclient) > set RHOSTS 192.168.0.2 msf5 auxiliary(scanner/scada/modbusclient) > set ACTION WRITE_COILS msf5 auxiliary(scanner/scada/modbusclient) > set DATA_ADDRESS 0 msf5 auxiliary(scanner/scada/modbusclient) > set DATA_COILS 11111111 msf5 auxiliary(scanner/scada/modbusclient) > run [*] Running module against 192.168.0.2 [*] 192.168.0.2:502 - Sending WRITE COILS... msf5 auxiliary(scanner/scada/modbusclient) > set DATA_COILS 00000000 msf5 auxiliary(scanner/scada/modbusclient) > run [*] Running module against 192.168.0.2 [*] 192.168.0.2:502 - Sending WRITE COILS...
Betrachten wir nun den Fall, dass sich der Angreifer außerhalb des lokalen Netzwerks befindet, aber über die Firewall Zugriff in das Segment mit der Steuerung hat. In diesem Fall ist der Netzwerkscan mit netdiscover (ARP-Scan) nicht möglich, ein nmap-Port-Scan oder Ping-Scan in den entsprechenden Netzwerkbereich funktioniert aber problemlos. Auch die Kommunikation mit der Steuerung über den Modbus Client wird funktionieren, es muss lediglich die IP-Adresse des Zielsystems bekannt sein.
Lassen Sie uns nun die bisher behandelten Schritte zusammenfassen: Die gezeigten Aktionen stellen noch keinen Angriff im eigentlichen Sinn dar, es handelt sich dabei lediglich um die Modbus-Standard-Funktionalität. Jeder Teilnehmer, der netzwerktechnisch Zugriff auf die Steuerung hat, kann diese Aktionen ausführen.
Im nächsten Schritt sollen die Möglichkeiten und Auswirkungen eines MITM-Angriffs (Man-in-the-Middle) durch den Angreifer im lokalen Netzwerksegment betrachtet werden. Gibt es in einem Netzwerksegment keine speziellen Schutzvorkehrungen, so kann ein Netzwerkteilnehmer mittels ARP-Spoofing eine Man-in-the-middle-Position einnehmen und den gesamten Datenverkehr zwischen zwei Netzwerkteilnehmern zu sich hin umleiten. Damit ist ein Mitschnitt der Datenkommunikation bis hin zu einer Manipulation der Daten möglich.
Eine ARP-Spoofing-Attacke kann einfach mit Tools wie arpspoof oder Ettercap erfolgen.
Nach dem Start von Ettercap und der Auswahl des Sniffing Interfaces wird ein Scan der verfügbaren Geräte im Netzwerk gestartet.
Im vorliegenden Beispiel soll der Datenverkehr zwischen der Engineering Station (192.168.0.20) und der Steuerung (192.168.0.2) zum Angreifer (192.168.0.30) umgeleitet werden. Dazu werden die beiden Adressen den Zielgruppen Target-1 und Target-2 zugewiesen.
Zur Veranschaulichung der ARP-Poisioning-Attacke lassen wir einen Ping von der Engineering-Station zur Steuerung laufen.
root@engineer:~# ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
64 bytes from 192.168.0.2: icmp_seq=1 ttl=30 time=1.42 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=30 time=0.799 ms
Betrachtet der Angreifer den Netzwerkverkehr auf seinem Netzwerkinterface, so sind die Ping-Pakete vor der Aktivierung des Angriffs aufgrund der Layer-2 Switch-Netzwerkstruktur nicht sichtbar.
Nach dem Start der Attacke sind plötzlich die ICMP-Pakete zwischen Engineering-Station und der Steuerung am Netzwerkinterface des Angreifers im Netzwerksniffer sichtbar – der Angreifer befindet sich nun in einer Man-in-the-Middle-Postion und kann den gesamten Datenverkehr mitlesen.
Ettercap erlaubt auch die Definition von Filterkriterien auf einzelne Datenpakete. Die folgende Filterkonfiguration ist nahezu selbsterklärend.
Sollte sich in einem Datenpaket mit der TCP-Ziel-Port-Adresse 502 eine Byte-Sequenz 0x08 0x01 0x00 befinden (dabei handelt es sich um die Ausschaltsequenz), so wird diese durch die Byte-Sequenz 0x08 0x01 0xff (der Einschaltsequenz) ersetzt. Der Filter muss noch kompiliert, in Ettercap geladen und aktiviert werden.
Die Auswirkungen dieses Angriffs könnten verheerend sein. Will der Benutzer auf der Engineering-Station das Ausschaltkommando an die Steuerung schicken, so ist dieses wirkungslos. Der Ausschaltbefehl wird kontinuierlich durch den Angreifer mit dem Einschaltbefehl überschrieben.
Zusammenfassung
Das Beispiel soll zeigen, welchen Impact ein Layer-2-Netzwerkzugang eines Angreifers in Kombination mit unverschlüsselter Datenkommunikation haben kann. Natürlich ist dabei einiges an krimineller Energie und Vorbereitungsarbeit nötig.
Wie können Sie sich nun vor derartigen Angriffen schützen? Sie müssen lediglich die Attack Kill Chain unterbrechen. Eine Kill Chain beschreibt die einzelnen Schritte, die für einen Angriff erfolgreich sein müssen. Wenn nur ein Schritt davon verhindert wird, so ist die Kette unterbrochen und der Angriff funktioniert nicht.
Im vorliegenden Fall ist das der Zugang zum Netzwerk, die Möglichkeit einer ARP-Spoofing-Attacke und der Einsatz eines unverschlüsselten Protokolls. Für alle diese Schritte gibt es Lösungen. Der Zugriff zum Netzwerk ist über 802.1x regelbar, ARP-Spoofing kann durch IDS-Systeme im Netzwerk oder durch Überwachung der lokalen ARP-Caches erkannt werden. Auch für die unverschlüsselte Datenübertragung gibt es eine Lösung. Im Jahr 2018 wurde eine sichere Variante von Modbus/TCP auf Basis TLS (Transport Layer Security) veröffentlicht. Eine Man-in-the-middle-Attacke wird durch die Nutzung von digitalen Zertifikaten verhindert.
- Shodan
- Wireshark
- Informatik Aktuell – Eric Amberg: Nmap – Portscanner, Hacking-Tool, Alleskönner (3-teilige Serie)
