Proseminar:

Werkzeugunterstützung für sichere Software

Software Engineering

Wintersemester 2014/15

Proseminar

Sichere Softwareentwicklung für speicherprogrammierbare Steuerungen

Alexander Kedzia

2. Februar 2015

Technische Universität Dortmund Fakultät Informatik

Lehrstuhl 14 Software Engineering – Prof. Dr. Jan Jürjens

betreut durch: Johannes Zweihoff

III

Alexander Kedzia

Alexander.kedzia@tu-dortmund.de

Matrikelnummer: 147698 Studiengang: Bachelor Informatik

Werkzeugunterstützung für sichere Software Thema: Sichere Softwareentwicklung für speicherprogrammierbare Steuerungen

Eingereicht: 2. Februar 2015

Betreuer: Johannes Zweihoff

Prof. Dr. Jan Jürjens Lehrstuhl 14 Software Engineering Fakultät Informatik Technische Universität Dortmund Otto-Hahn-Straße 14 44227 Dortmund

IV

Ehrenwörtliche Erklärung Ich erkläre hiermit ehrenwörtlich, dass ich die vorliegende Arbeit selbstständig angefertigt habe. Sämtliche aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche kenntlich gemacht.

Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und noch nicht veröffentlicht.

Dortmund, den 2. Februar 2015 ___________________________

Unterschrift

Abstract V

Abstract Programmable Logic Controllers are the key structure when it comes to attacking Industrial facilities. They interface between the industrial machines and the SCADA-System (Supervisory control and data acquisition), which is used to monitor and control the site. By gaining access to the SCADA-System one gets control over all its components and thereby also over the Programmable Logic Controllers. This is why safe software architecture for these systems is needed.

This report focuses on explaining the basics of the commonly used SCADA-Systems and showing of their main components. It demonstrates the often used zone architectures – Demilitarized Zone and Single Firewall Zone – and also gives insight about the important factors of software development for these Systems.

Moreover the most used attack vectors onto these SCADA-Systems are presented by using the introduced structural view of the system. It focuses on attack from the Office Zone, Substations and the Control Center itself.

The obtained information about the SCADA-System and common attack vectors is used to recommend future changes in live systems and systems still in development.

Inhaltsverzeichnis VI

Inhaltsverzeichnis

Ehrenwörtliche Erklärung .......................................................................................................... IV

Abstract ...................................................................................................................................... V

Inhaltsverzeichnis ...................................................................................................................... VI

Abbildungsverzeichnis ............................................................................................................. VIII

1 Einleitung ............................................................................................................................ 9

2 SCADA-System-Struktur ...................................................................................................... 9

2.1 Substations ................................................................................................................ 10

2.1.1 RTUs und PLCs .................................................................................................... 10

2.1.2 Field instruments ................................................................................................ 11

2.2 Control center ............................................................................................................ 12

2.2.1 Front-End-Server ................................................................................................ 13

2.2.2 SCADA-Server ..................................................................................................... 13

2.2.3 Historian ............................................................................................................. 13

2.2.4 Operator HMI Client ........................................................................................... 14

2.2.5 Operator HMI Server .......................................................................................... 14

2.2.6 Data engineering server ..................................................................................... 15

2.2.7 Inter Control Center Communication Cerver ..................................................... 15

2.3 Office ......................................................................................................................... 15

2.4 Demilitarisierte Zone ................................................................................................. 16

2.5 Single Firewall Architecture ....................................................................................... 18

2.6 Zwischenfazit ............................................................................................................. 18

3 Softwareentwicklung ........................................................................................................ 19

3.1 Entwicklung ............................................................................................................... 19

3.1.1 Substation ........................................................................................................... 19

3.1.2 Kontrollzentrum ................................................................................................. 19

3.1.3 DMZ .................................................................................................................... 20

3.2 Auslieferung ............................................................................................................... 20

3.3 Wartung ..................................................................................................................... 20

4 Angriffsvektoren ............................................................................................................... 20

4.1 Angriffe aus den Substationen .................................................................................. 20

Inhaltsverzeichnis VII

4.1.1 Heap Overflow .................................................................................................... 21

4.2 Angriffe aus dem Internet ......................................................................................... 21

4.2.1 SQL Injection ....................................................................................................... 21

4.2.2 Cross-Site Request Forgery ................................................................................. 22

4.2.3 Default Login ....................................................................................................... 22

4.2.4 HMI to PLC .......................................................................................................... 22

4.2.5 Web Backdoor .................................................................................................... 22

4.3 Angriffe aus dem Kontrollzentrum ............................................................................ 22

4.3.1 Stuxnet ................................................................................................................ 23

5 Fazit ................................................................................................................................... 23

Literaturverzeichnis .................................................................................................................. 24

Abbildungsverzeichnis VIII

Abbildungsverzeichnis Abbildung 1 Substation PLC/RTU Interaktionen mit Feldinstrumenten .................................. 10

Abbildung 2 Kontrollzentrum mit einzelnen Komponenten .................................................... 12

Abbildung 3 SCADA-System mit DMZ Architektur ................................................................... 17

Abbildung 4 Single firewall ....................................................................................................... 18

Einleitung 9

1 Einleitung Die meisten der heutigen Industrieanlagen benutzen Supervisory Control and Data Acquisition-Systeme (SCADA-Systeme) zur Überwachung und Steuerung ihrer Aufgaben. Sie zählen zu den industriellen Kontrollsystemen (engl. Industrial control systems, ICS), unterscheiden sich jedoch von anderen durch weitreichende Prozesse und eine Verteilung über viele Anlagen. Dazu gehören unter anderem Anlagen der Energie- und Trinkwasserversorgung, Öl- und Gas-Pipelines oder auch Nuklearanlagen. Ein wichtiger Bestandteil dieser SCADA-Systeme sind die speicherprogrammierbaren Steuerungen (engl. Programmable Logic Controller, PLC). Sie bilden die Schnittstelle zwischen dem SCADA-System und den Maschinen der Anlage und haben zudem Zugriff auf die Steuerung dieser.

Die Vergangenheit hat bereits gezeigt, dass diese ein beliebtes Ziel für terroristische Angriffe sind. Ein Beispiel dafür ist der Wurm „Stuxnet“ der speziell für eine Nuklearanlage im Iran entworfen wurde und dort über das SCADA-System Zugriff auf die PLCs bekommen hat. Durch diese konnte dann eine geringfügige, kaum erkennbare, Veränderung der Turbinenumdrehungen eingeschleust werden, was zu einem stark erhöhten Verschleiß dieser geführt hat. Die Gerissenheit und extrem spezialisierte Implementierung zeigte, dass größere Organisationen dahinter stecken und SCADA-Systeme hohen Sicherheitsansprüchen genügen müssen. 1

Im weiteren Verlauf dieser Arbeit werden SCADA-Systeme und PLCs auf ihre Sicherheitsaspekte untersucht. Dazu wird zunächst in Kapitel 2 die typische Struktur dieser SCADA-Systeme aufgezeigt und ihre einzelnen Bausteine erklärt. Das darauf folgende Kapitel beschäftigt sich mit dem Softwareentwicklungsprozess der Systeme und geht auf die Produktion, die Auslieferung und die Wartung ein. Kapitel 4 zeigt einige häufig vorkommende Angriffsvektoren auf, sowie welche Schwächen des Systems ausgenutzt wurden. Im letzten Kapitel werden Rückschlüsse auf mögliche Verbesserungen der vorhandenen und zukünftig geplanten SCADA-Systeme erarbeitet und offene Probleme in der Struktur, sowie dem Softwareentwicklungsprozess angesprochen.

2 SCADA-System-Struktur Um die Angriffe auf SCADA-Systeme besser verstehen und analysieren zu können, wird in diesem Kapitel ein Einblick in die Architektur dieser gegeben. Hierfür werden zu nächst die am häufigsten vorkommenden Strukturen vorgestellt und die darin vorkommenden Komponenten beschrieben. Außerdem werden die zurzeit angewandten Kommunikationsprotokolle zwischen den einzelnen Komponenten vorgestellt.

1 Vgl. PY12, S1.

SCADA-System-Struktur 10

2.1 Substations Substationen bilden die äußerste Einheit innerhalb des SCADA-Systems. Sie bestehen aus PLC’s und Feld-Instrumenten, wobei erstere die Steuerung der Instrumente – z.B. Turbinen oder Zylinder – übernehmen. Die meisten Anlagen besitzen innerhalb, als auch außerhalb der eigentlichen Anlage, viele dieser Stationen und sind über WAN mit dem restlichen System verbunden.

Abbildung 1

Substation

PLC/RTU Interaktionen mit Feldinstrumenten2

2.1.1 RTUs und PLCs

Remote Terminal Unit (RTUs) sowie PLCs dienen dem SCADA-System als Schnittstelle mit den Feldinstrumenten der Anlage. Sie besitzen umfangreiche Input/Output (I/O) Möglichkeiten, die es ihnen ermöglichen mit Sensoren und Aktoren zu kommunizieren. Dadurch können sie die verschiedenen Maschinen der Anlage regeln und kontrollieren. Sie lesen analoge Prozessvariablen wie Temperatur und Druck aus oder auch Umdrehungen oder Füllstände. Diese Informationen werden dann digital an das SCADA-System geleitet, um entsprechend der Konfiguration des Systems, die Feldinstrumente zu regulieren.

2 Vgl. Wil13, S2-3

SCADA-System-Struktur 11

Die Kommunikation erfolgt hierbei über verschiedene Protokolle wie MODBUS, DNP3, EtherNET/IP, PROFIBUS und Fieldbus.3

Der Hauptunterschied zwischen RTUs und PLCs besteht darin, dass RTUs besser für Langstrecken-Kommunikation geeignet sind, da sie unter anderem bereits kabellose Verbindungsmöglichkeiten mitbringen. PLCs dagegen sind deutlich robuster gegenüber äußerlichen Gegebenheiten, wie Staub, Feuchtigkeit oder Hitze und eignen sich somit hervorragend zum Einsatz an Maschinen, die extreme Bedingungen erfordern und kritische Prozesse überwachen. 4

2.1.2 Field instruments

Zu den Feld-Instrumenten gehören unter anderem elektrische Motoren, pneumatische oder hydraulische Zylinder, magnetische Relais, Wasser-Pumpen oder, wie im Fall des Stuxnet-Wurms, Turbinen.

3 Vgl. BFM04, S1

4 Vgl. A08, S9

SCADA-System-Struktur 12

2.2 Control center Das Kontrollzentrum (engl. Control Center) ist der Kern des SCADA-Systems. Hier werden alle vitalen Funktionen der Anlage gehalten, wie z.B. den Historian zur Verwaltung der aufkommenden Daten oder dem SCADA-Server. Dieser verteilt die entstehenden Daten an die entsprechenden Empfänger und leitet Kommandos aus den Human-Machine Interfaces (HMI) an die Substationen weiter.

Abbildung 2

Kontrollzentrum mit einzelnen Komponenten5

5 Vgl. B10 S24 und S67

SCADA-System-Struktur 13

2.2.1 Front-End-Server

Die Front-End-Server sind für die Kommunikation zwischen Kontrollzentrum und den einzelnen Substationen zuständig. Sie übertragen Kommandos zu den RTU/PLC-Einheiten und stellen Sollwerte ein. Zudem empfangen sie Rohdaten der Substationen und wandeln diese in technische Daten um oder wandeln Hardware-Adressen der RTUs/PLCs in logische Datenbank-Adressen innerhalb des SCADA-Servers um.6

In den meisten Konfigurationen werden 2 Front End-Server verwendet, um bei Ausfall eine Alternativlösung zur Verfügung zu haben.

2.2.2 SCADA-Server

Der SCADA-Server bildet das Herzstück der Anlage und ist mit allen Geräten direkt oder indirekt verbunden. Die vom Front-End-Server verarbeiteten Prozessinformationen werden an den SCADA-Server gesendet und in einer Echtzeit-Datenbank festgehalten. Diese repräsentiert ein SCADA-Modell der überwachten Anlage, in welchem alle Informationen über den aktuellen Zustand enthalten sind. Dies wird durch ein ständiges Update des Modells mit Hilfe der vom Front-End-Server erhaltenen Daten realisiert.

Hauptaufgabe des SCADA-Servers ist es, die Anlage möglichst konsistent am Laufen zu halten. Dafür werden die Prozesse auf Auffälligkeiten und Unzulänglichkeiten beobachtet und dem Personal verdächtige Veränderungen aufgezeigt. Dies kann zum Beispiel eine Abweichung in der eingestellten Drehzahl einer Turbine sein oder zu hohe Spannung auf einer Leitung.

Alle Prozesseigenschaften, Ereignisse und Personaleingriffe werden aufgezeichnet und können abgerufen werden. Außerdem werden dem Personal Warnungen vom System angezeigt, die deren Aufmerksamkeit bedürfen. Das Personal bezieht Zugriff über die HMI-Clients und kann über diese auch Befehle an das System liefern.

Der SCADA-Server verfügt zudem auch noch über Ausfallsicherung, die im Falle von Problemen mit Hardware oder Software vorbestimmte Schritte einleitet um Schaden zu vermeiden/minimieren.

Parallel zu den sonstigen Tätigkeiten wird außerdem der Historian permanent mit dem Modell des SCADA-Servers versorgt. 7

2.2.3 Historian

Damit alle Informationen über das System und das zugrunde liegende SCADA-Modell nicht verloren gehen, wird ein Historian benutzt um die gesammelten Daten und

6 Vgl. B10 S24

7 Vgl. B10, S26-27.

SCADA-System-Struktur 14

Prozessinformationen zu speichern. Dieser bezieht seine Daten direkt aus dem SCADA-Server und ist nur wenige Sekunden hinter dem aktuellen Zustand des Modells. Der Historian hat verschiedene Nutzeigenschaften8:

Speichern von Prozessdaten, Ereignissen/Alarme, Personalaktionen, Berechnungen

Definition von spezifischen Anwenderberechnungen, z.B. das Volumen des gefilterten Wassers der letzten Tage/Wochen/Monate

Abspielen von vergangenen Prozessdaten zur Analyse

Präsentation von Trends und Berichten

Data Mining

2.2.4 Operator HMI Client

Der Operator HMI Client ist die Schnittstelle, an der menschliche Interaktionen durchgeführt werden können. Hier wird das SCADA-Modell mit Hilfe verschiedener Ansichten visualisiert und dem Personal angezeigt. Dies geschieht nicht über eine simple Shell, sondern meist über eine grafische Arbeitsstation. Das Personal kann Kommandos an die Substationen senden und hat dadurch starke Kontrolle über die gesamte Anlage. Dazu stehen ihnen verschiedene Werkzeuge zur Verfügung:

Schematische und Geographische Displays zur Visualisierung des Netzwerkzustandes in Echtzeit

Ereignis- und Alarmlisten

Trends und Berichte

Tabellen Displays

Kontrollsystem Status- und Konfigurations-Displays

Wartungs und Diagnose Displays

Zugriff auf diese Clients wird meist über Authentifizierungsverfahren auf bestimmte Bereiche begrenzt, damit jedem Mitarbeiter nur sein entsprechender Bereich zur Verfügung steht9.

2.2.5 Operator HMI Server

Viele SCADA-Systeme erlauben Zugriff von Remote-Clients, also Arbeitsstationen die nicht direkt im Kontrollraum installiert sind. Über den Operator HMI Server können sie dieselben Funktionalitäten nutzen wie Operator HMI Clients, müssen sich aber natürlich auch erst

8 Vgl. B10 S29-30.

9 Vgl. B10, S30

SCADA-System-Struktur 15

Authentifizieren. Zur Verbindung werden häufig Systeme wie VNC, Terminalserver oder Citrix genutzt10.

2.2.6 Data engineering server

Das SCADA-Modell zur internen Repräsentation der Anlage ist sehr komplex, aufgrund der Menge an Prozessen und Objekten die überwacht und gesteuert werden müssen. Darum gibt es von den verschiedenen Anbietern Hilfsmittel, die dem Nutzer helfen dieses Modell effizient zu erstellen und zu warten. Dies geschieht auf dem Data engineering server, der meist auf einer relationalen Datenbank wie Oracle basiert. Zu den Hilfsmitteln gehören11:

Definitionen aller SCADA-Objekte (Messwerte und Status Informationen)

Definitionen aller Prozessobjekte wie Leitungen, Isolatoren, Busse, Generatoren, Turbinen, etc.

Definitionen für Verbindungen, z.B. wie verschiedene Prozessobjekte untereinander verbunden sind.

Definition der RTUs/PLCs und Protokolle

Verbindungen zwischen SCADA-Objekten und RTU/PLC I/O

Definition für Kontrollparameter wie Alarm- und Ereignisbehandlung Strukturen des Historian und Definition der zu speichernden Daten

Desweiteren stellt der Data engineering server oft Systeme zum aktualisieren der aktuellen Version im laufenden System und Möglichkeiten alte Versionen wiederherzustellen.

2.2.7 Inter Control Center Communication Cerver

Durch den Anschluss des SCADA-Systems an einen Inter Control Center Communication Server, kann das Kontrollzentrum Daten mit anderen Zentren austauschen. Dies kann z.B. von Vorteil sein, um Informationen mehrerer Stromkraftwerke auszutauschen und eine Intelligente Stromzufuhr zu organisieren12.

2.3 Office Das Office ist der letzte der 3 Hauptbereiche innerhalb des SCADA-Systems. Es beinhaltet die PCs für einen Großteil der Mitarbeiter und ermöglicht unter anderem Tätigkeiten wie das erstellen von Berichten, planen von Arbeiten innerhalb des Systems oder auch versenden von E-Mails.

10 Vgl. B10, S31

11 Vgl. B10, S33-34

12 Vgl. B10, S40

SCADA-System-Struktur 16

Damit diese funktionieren, wird Zugriff auf verschiedene Bestandteile des Kontrollzentrums gebraucht. Unter anderem müssen die Daten des Historian zugänglich sein, als auch Zugriff zum Application-Server gewährleistet sein.

Da das Internet für die meisten im Office getätigten Arbeiten unabdingbar ist, ist es mitunter die unsicherste Zone der 3 Bereiche und zwingt die SCADA-Systeme zu bestimmten Sicherheitsmaßnahmen.

Dafür werden von den SCADA-Anbietern verschiedene „Zonen“-Lösungen geboten, um die wichtigen Bestandteil des Systems vor Angriffen von außen zu schützen.

2.4 Demilitarisierte Zone Die Idee der demilitarisierten Zone (engl. Demilitarized Zone, DMZ) ist es, dass jeglicher Traffic, der aus dem Office kommt, auch in dieser endet. Dadurch wird das Kontrollzentrum isoliert und vor Angriffen geschützt.

Damit jedoch trotzdem die gewünschten Funktionen erhalten bleiben, müssen gewisse Änderungen am Aufbau des SCADA-Systems getätigt werden.

SCADA-System-Struktur 17

Abbildung 3

SCADA-System mit DMZ Architektur13

Damit weiterhin in der Office-Zone die Daten des Historian verfügbar sind, wurde in der DMZ eine Kopie dieses angelegt. Sie wird ständig mit den aktuellen Daten des Historian im Kontrollzentrum aktualisiert und sein Inhalt ist nur wenige Sekunden veraltet im Vergleich zum Original. Jeglicher Zugriff, der vorher ins Kontrollzentrum ging, findet nun auf der Kopie statt.

Der HMI Server für Fernzugriffe wurde zusammen mit dem Inter Control Center Communication Server in die DMZ verlegt und gibt dem Nutzer nur Zugriff auf die HMI Clients innerhalb der DMZ.

Diese Architektur hat zum Vorteil, dass Kontrollzentrum vom Office und somit auch vom Internet isoliert ist. Dies hat den Vorteil, dass ältere SCADA-Systeme, die noch unter der Voraussetzung entwickelt wurden, dass sie in einem abgeschotteten System arbeiten, modernisiert und abgesichert werden. Desweiteren bleiben die Funktionalität des Systems erhalten.

Leider führt dies dazu, dass Angreifer leichtes Spiel haben, sobald sie einmal in die DMZ eingedrungen sind oder einen Weg gefunden haben diese zu umgehen, da angenommen

13 Vgl. B10 und MSS12, S5.

SCADA-System-Struktur 18

wird, dass sie dort nicht hingelangen können und somit weitere Sicherheitsmaßnahmen nur begrenzt sind14.

2.5 Single Firewall Architecture In SCADA-Systemen, die diese Architektur verwenden, gibt es nur zwei Zonen: Das Office und das Kontrollzentrum. Diese kommunizieren direkt miteinander und werden nur von einer einzigen Firewall getrennt.

Abbildung 4

Single Firewall15

Dieser Aufbau wird nur noch selten in neuen Anlagen verwendet, ist jedoch immer noch stark präsent in bereits laufenden. Das Problem an dieser Architektur ist, dass ein Angreifer es nur schaffen muss, die Firewall zu umgehen und danach bereits vollen Zugriff auf das SCADA-System hat.

2.6 Zwischenfazit Nachdem wir nun einen Überblick über die verwendeten SCADA-Systeme und deren Architektur bekommen haben, können wir bereits mögliche Schwachstellen und Angriffsziele

14 Vgl. B10, S64-65

15 Vgl. B10, S67-68

Softwareentwicklung 19

ausmachen. So wird ein potenzieller Angreifer häufig die Absicht haben die Ausstattung der Anlage zu beschädigen. Hierfür benötigt er letztendlich Kontrolle über die RTUs/PLCs. Sobald ihm dies gelungen ist, kann er die Anlage zu seinem Belieben manipulieren.

Es ergeben sich verschiedene Angriffspfade, wie z.B. über direkten Einstieg an einer abgelegenen Substation oder indem er sich Zugriff zum Kontrollzentrum über das Office beschafft. Dazu folgt später mehr in Kapitel 4. Nun werden wir erst die Softwareentwicklung für SCADA-Systeme betrachten und analysieren welche Aspekte besonders wichtig sind um die Sicherheit von PLCs zu gewährleisten.

3 Softwareentwicklung Wie wir bereits wissen, sind die einzelnen Bestandteile des SCADA-Systems über eine größere geographische Fläche verteilt. Dies hat zur Folge, dass Kommunikation, zwischen diesen einzelnen Standorten nötig ist. Die Software muss deshalb in der Lage sein die Befehle und Daten untereinander auszutauschen. Damit dies sicher erfolgen kann dürfen nur authentifizierte Benutzer Daten auslesen und verändern.

3.1 Entwicklung Bereits während der Entwicklung der Software müssen bestimmte Kriterien eingehalten werden, um das System später zu schützen. Diese müssen speziell für jede Komponente entworfen werden.

3.1.1 Substation

Keine der Substationen sollte in der Lage sein Zugriff auf das Kontrollzentrum zu bekommen. Dafür sollten die empfangbaren Daten im Front-End-Server bereits definiert sein und Ausnahmeregelungen speziell abgefangen werden. Alle Daten die nicht den typischen Messwerten entsprechen sollten kontrolliert werden.

Damit eine Manipulation der Daten zusätzlich erschwert wird, sollte außerdem jegliche Kommunikation mit den Substationen verschlüsselt erfolgen.

3.1.2 Kontrollzentrum

Die im Kontrollzentrum verwendete Software sollte Schwerpunkte auf der Authentifizierungs -und Zugriffskontrolle haben. Dabei sollten jegliche Daten die aus den unsicheren Zonen wie dem Office oder den Substationen über Firewalls gefiltert werden und auf Integrität geprüft werden.

Auch, wenn es aufwändiger ist, sollten die meisten Übertragungen in gesicherten Sitzungen ablaufen um das einschmuggeln von gefälschten Datenpaketen von außen zu erschweren.

Angriffsvektoren 20

3.1.3 DMZ

Für die meisten SCADA-Systeme, die eine Office Zone besitzen, sollte diese Architektur gewählt werden, da sie das Kontrollzentrum vom Rest des Systems absichert und Zugriff von außen erschwert. Falls doch Fernsteuerung zugelassen werden soll, erfolgt dies am besten über gesicherte VPN-Verbindungen.

Ebenfalls die Auslagerung des Historian durch eine Kopie bietet guten Schutz für das Kontrollzentrum.

3.2 Auslieferung Bei der Auslieferung und Installation des Systems sollte ein Protokoll zur Einrichtung der Anlage befolgt werden, das gewährleistet, dass Komponenten, die noch nicht vollständig mit dem restlichen System verbunden sind oder deren Sicherung noch nicht aktiv ist keine Anbindung an die Außenwelt besitzt, da das System in dieser Phase noch sehr anfällig ist.

Zudem sollte eine Sicherheitsschulung für die im Kontrollzentrum arbeitenden Mitarbeiter durchgeführt werden, um sie mit den Routinen zum Schutz des Systems vertraut zu machen. Dabei sollten Standard-Passwörter, etc. verändert werden.

3.3 Wartung Das Entwicklerteam sollte Schnittstellen bereithalten, mit denen Notfalls schnell Änderungen am System durchgeführt werden können, falls kritische Systemlücken entdeckt werden und schnell behoben werden müssen. Hierbei ist jedoch Vorsicht geboten, um dem Angreifer nicht noch eine zusätzliche Angriffsfläche zu bieten.

Zudem ist ein Intrusion-Detection-System innerhalb des Kontrollzentrums zu empfehlen, um Angriffe Identifizieren zu können und dementsprechende Sicherheitsvorkehrungen treffen zu können.

4 Angriffsvektoren Angreifern stehen verschiedene Möglichkeiten zum Eingriff in ein SCADA-System zur Verfügung. Im nachfolgenden Kapitel werden einige dieser aus den jeweiligen Zonen – Substation, Office und Kontrollzentrum - beschrieben.

4.1 Angriffe aus den Substationen Die Substationen eignen sich hervorragend für einen Angriff auf das SCADA-System, da sie meist unbemannt und physisch, gegenüber einem entschlossenen Angreifer, nur schwach gesichert sind. Die Verbindung zum Kontrollzentrum macht sie zum idealen Ziel, da so Kontrolle über das gesamte System gewonnen werden kann.

Angriffsvektoren 21

Das häufig zwischen diesen Zonen verwendete Kommunikationsprotokoll MODBUS hat einige offene Probleme16:

Alle Nachrichten werden in Klartext versendet

Es ist kein Integritätscheck vorhanden

Keine Authentifizierung ist nötig

TCP hält Record-Boundaries nicht ein

Keine wirkliche Sitzung

Dies ermöglicht einem potenziellen Angreifer das einschmuggeln seiner eigenen Daten, ohne, dass das System dies bemerkt. Außerdem können die Nachrichten auch abgefangen und gelesen werden. Das Team von C4 machte sich diese Eigenschaften zu Nutze und zeigte beispielhaft wie man sich unerlaubt Zugriff verschaffen kann.17

4.1.1 Heap Overflow

In einem simulierten System von GE-Fanuc’s Cimplicity HMI 6.1, ein Pipeline-Kontrollzentrum, schickten sie leicht korrupte Pakete an den Front-End-Server. Bereits nach kurzer Zeit stürzte das System durch einen Heap overflow ab.

Analysen ergaben, dass dies durch ein zu großes Paket, welches das System in ein Buffer schreiben möchte, der eine festgelegte Größe hat. Dies ermöglicht es eine 32bit Adresse durch eine Adresse seiner Wahl zu überschreiben. Wählt man nun eine Adresse aus, die vom Exception-Handler des Systems genutzt wird und überschreibt sie mit der des Heaps, kann man eignen Code auf dem Server ausführen lassen.

Danach ist es einfach eine remote Shell zu öffnen und kompletten Zugriff über das SCADA-System zu erlangen18.

4.2 Angriffe aus dem Internet Da das Office meist eine Anbindung an das Internet, sowie das Kontrollzentrum besitzt, ist es ebenfalls ein beliebter Weg für Angriffe auf das SCADA-System. Hierfür gibt es einige häufige Angriffswege19.

4.2.1 SQL Injection

Der Angreifer versucht über den HMI-Client in der DMZ Zugriff auf die im Hintergrund liegende Datenbank zu erhalten und so ins Kontrollzentrum einzudringen. Dabei wird SQL

16 Vgl. BFM04 S7-9.

17 Vgl. Uda08, S3-4

18 Vgl. Uda08 ebd

19 Vgl. Wil13, S11-12.

Angriffsvektoren 22

Code in Eingabefelder übertragen in der Hoffnung, dass die Datenbank diesen unfreiwillig ausführt und somit dem Angreifer Möglichkeiten bietet eigenen Code in das System zu schmuggeln.

4.2.2 Cross-Site Request Forgery

Auch hier versucht der Angreifer Code auf dem Server auszuführen, ohne die Berechtigung dafür zu haben. Er führt den Browser des Ziels dazu unfreiwillig ein HTTP-Request auszuführen, der durch Nebeneffekte Zugriff für den Angreifer ermöglicht.

4.2.3 Default Login

Dabei versucht der Angreifer Standard-Logindaten zu verwenden, um in das System zu gelangen. Kombinationen wie „Admin“ und „1234“ werden dafür häufig genutzt, in der Hoffnung, dass der Administrator vergessen hat die Defaults zu verändern

4.2.4 HMI to PLC

Kommunikation zwischen HMI und PLC findet unter anderem über das Modbus-Protokoll statt. Angreifer versuchen die Daten dazwischen zu modifizieren und Kommandos auszuführen. Da die Übertragung unverschlüsselt und ohne Authentifizierung erfolgt, ist auch dies ein häufiges Ziel.

4.2.5 Web Backdoor

C4 hat noch einen weiteren Angriffsvektor auf das System von GE-Fanuc’s durchgeführt. Dafür haben sie zunächst mit einem Network-Sniffer jegliche Kommunikation zwischen Client und Server aufgezeichnet. Dadurch konnten sie ein Login-Paket ausfindig machen um gültige Authentifizierungsdaten zu erhalten.

Weiterhin beobachteten sie, wie der Client eine Datei auf dem Server erstellt hat und stellten den Vorgang nach, um eine eigene Datei einzubringen und auszuführen. So erhielten sie Zugriff auf eine Shell und demnach das gesamte SCADA-System20.

4.3 Angriffe aus dem Kontrollzentrum Nicht alle SCADA-Systeme sind mit dem Internet verbunden oder haben angreifbare Substationen. Dies erfordert ein anderes Vorgehen zum erlangen der Kontrolle über das SCADA-System. Erwähnenswert ist hierbei der Wurm „Stuxnet“ der bis 2010 in der Nuklearanlage Natanz gewirkt hat und mehrere hundert Zentrifugen der Nuklearanlage zerstört hat.

20 Vgl. Uda08, S6-9.

Fazit 23

4.3.1 Stuxnet

Ursprünglich musste der Wurm über ein USB-Stick in die Anlage gebracht werden, wie z.B. durch einen falschen Mitarbeiter. Einmal drin, verbreitet sich der Virus kontrolliert um sein endgültiges Ziel, die PLCs zur Steuerung der Zentrifugen, zu erreichen. Dazu nutzt es mehrere Techniken.

Über die WinCC Bibliothek verbindet es sich durch ein festgelegtes Passwort mit WinCC und läd durch SQL Befehle eine Kopie von sich selbst auf den WinCC Computer.

Über gemeinsame Ordner im Netzwerk verbreitet es sich dort, indem es dort eine Datei ablegt und dafür sorgt, dass diese von den anderen Computern ausgeführt wird.

Über den MS10-061 Drucker-Buffer-Exploit kann Stuxnet zwei Dateien in das System der Zielcomputer „drucken“ und dort ausführen.

Über den MS08-067 SMB exploit kann es einen gefälschten Pfad über das sharing-protocol SMB übertragen und so eigenen Code auf dem Zielrechner ausführen.

Über Step7 Projekte kann es sich in die Bibliothek dieser Projekte einführen und somit auch auf andere Computer, die diese Projektdatei nutzen, überspringen.

Dabei ist jedoch zu Bemerken, dass Stuxnet sich nur auf bis zu drei Computer gleichzeitig verteilt und immer wieder von einem zum anderen wandert. Wenn es einen Computer erreicht, der Zugriff auf die PLCs hat, umschließt es die Bibliothek die zur Kommunikation mit diesem benutzt wird und hat somit Kontrolle über sämtliche Informationen die zwischen diesen ausgetauscht werden. So verändert es die Arbeitsweise nach Belieben, ohne dass Auffälligkeiten vom System gemeldet werden21.

5 Fazit Da SCADA-Systeme geographisch verteilt agieren sind sie eine Herausforderung für Softewareentwickler. Es muss gelingen die einzelnen Komponenten zu überwachen und zu koordinieren. Da ihr Einfluss innerhalb der Anlage sehr groß ist, bilden sie ein beliebtes Ziel für Angriffe von außen und müssen viele Sicherheitsmaßnahmen ergreifen.

Probleme bereiten dabei die einzeln verteilten Stationen die dem Angreifer viel Angriffsfläche bieten und das System verwundbar machen. Deshalb müssen bereits bei der Softwarentwicklung, besonders bei der Auswahl der Architektur, Sicherheitsaspekte eine hohe Rolle spielen.

Auch wenn viele der Angriffsvektoren abgewendet werden könnten, indem die Sicherheitsstandards der verwendeten Protokolle erhöht werden würden. (z.B.

21 Vgl. PY12 S5-7.

Fazit 24

Verschlüsselung der übertragenden Daten) Ist dies noch nicht in allen Systemen angekommen und bietet Angreifern leichtes Spiel.

Hinzu kommt, dass SCADA-Systeme von hochkarätigen Organisationen ins Ziel genommen werden und so in den meist komplexen Systemen der kleinste Fehler ausgenutzt werden kann um immensen Schaden anzurichten.

Somit müssen die benutzen Sicherheitsverfahren immer weiter entwickelt werden um auch in Zukunft sicher(er) sein zu können.

Literaturverzeichnis [B10] G. Björkman et al. “Vital Infrastructure, Networks, Information and Control Systems

Management - VIKING”.

[BFM04] Eric J. Byres, Matthew Franz and Darrin Miller. Lisbon Portugal, 2004. “The Use of Attack Tress in Assessing Vulnerabilities in SCADA Systems” In: Internatinal Infrastructure Surviability Workshop (IISW’ 044).

[PY12] Paul Mueller and Babak Yadegari. University of Arizone 2012 “The Stuxnet Worm”.

[Uda08] Eyal Udassin. S4 Conference, 2008. “Control System Attack Vectors and Examples: Field Site and Corporate Network”.

[Wil13] Kyle Wilhoit. Black Hat Archives, 2012. “The SCADA That Didn’t Cry Wolf – Who’s Really Attacking Your ICS Equipment? (Part2)”.

[MSS12] Zhendong Ma, Paul Smith and Florian Skopik. Austrian Institute of Technology 2012. “Towards a Layered Architectural View for Security Analysis in SCADA Systems”. In: eprint arXiv: 1211.3908.

[DS99] A. Daneels and W. Salter. Cern, Geneva, Switzerland. “WHAT IS SCADA?” In: Internatinal Conference on Accelerator and Large Experimental Physics Control Systems 1999, Trieste, Italy”.

[A08] P. Abinandhan. “Study and Implementation of Programmable Logic controller”. In: Department of Electronics & Communication Engineering, Natinal Institute of Technology, Rourkela, Orissa -769008.