Die Gefahr besteht, dass ein Webserver schädlichen Code ausführt, weil er nicht überprüft was für Code es ist und von wem er kommt.

Die Gefahr besteht, dass ein Webserver schädlichen Code ausführt, weil er nicht überprüft was für Code es ist und von wem er kommt.Artur Marciniec – Fotolia.com

Durch das Internet der Dinge (IoT), Cyber-physikalische Systeme und Industrie 4.0 wird die Anzahl der vernetzten Baugruppen in der Automatisierung in den nächsten Jahren stark anwachsen. Da praktisch jedes System zumindest eine webbasierte Benutzerschnittstelle für Inbetriebnahme- und Serviceaufgaben besitzt, steigt auch die Anzahl möglicher Angriffspunkte. Um derartige Schnittstellen besser zu schützen, besteht aus Expertensicht akuter Handlungsbedarf.

In unzähligen Automatisierungsnetzwerken wird von einem PC aus auf die Web-Oberfläche eines Feldgeräts zugegriffen. Dabei gibt der PC-Benutzer am Anfang einer Sitzung in der Regel einen Benutzernamen und ein Passwort auf einer Anmelde-Webseite ein. Die gesamte Kommunikation zwischen PC und Automatisierungskomponente kann innerhalb des LANs von jedem x-beliebigen Rechner aus relativ einfach abgehört, aufgezeichnet und auch an einen unautorisierten Dritten im Internet übermittelt werden. Dadurch kommt ein potenzieller Angreifer auch in den Besitz der Passwörter. Das funktioniert so: In einer typischen Netzwerkkonfiguration bildet ein Ethernet-LAN-Switch die zentrale Infrastrukturbaugruppe. Alle Systeme eines Netzwerks sind sternförmig mit den einzelnen Switch-Ports verbunden. Im Switch existiert eine Adresstabelle, in der festgehalten wird, welches System oder welche Ethernet-MAC-Adresse mit welchem Port verbunden ist. Mithilfe dieser Tabelle laufen die Datenpakete bei der Kommunikation zweier Rechner im LAN nur über die jeweiligen Kabelverbindungen zwischen dem betreffenden System und dem Switch-Port. Alle anderen Rechner am gleichen Switch bekommen diese Datenpakete nicht zu sehen.

Durch die sternförmige Topologie typischer Ethernet-LANs läuft ein Datenpaket, das von System C an B gesendet wird, nur über die betroffenen Ports des Ethernet-Switch. Mit einem Angriffswerkzeug wie Arpspoof lässt sich das aber ändern, um zum Beispiel Sys

Durch die sternförmige Topologie typischer Ethernet-LANs läuft ein Datenpaket, das von System C an B gesendet wird, nur über die betroffenen Ports des Ethernet-Switch. Mit einem Angriffswerkzeug wie Arpspoof lässt sich das aber ändern, um zum Beispiel SysSSV Software

Aus dem Switch-Verhalten lässt sich allerdings nicht schlussfolgern, dass die Kommunikation zwischen zwei LAN-Systemen nicht ohne Weiteres durch ein drittes System abgehört werden kann. Es existiert zum Beispiel mit Arpspoof ein Werkzeug, mit ein Angreifer von einem dritten Rechner aus die Kommunikation zweier anderer Systeme im gleichen LAN abhören und jederzeit durch einen Man-in-the-Middle-Angriff manipulieren kann, ohne dass die anderen Systeme im LAN etwas davon mitbekommen. Ein Eingriff in die LAN-Verkabelung ist dafür nicht erforderlich. Es wird zunächst das sogenannte Packet-Forwarding aktiviert und auf dem Rechner eingeschaltet, von dem aus der Man-in-the-Middle-Angriff erfolgt. Dadurch leitet dieser Rechner abgehörte LAN-Pakete au den tatsächlichen Adressaten weiter – zum Beispiel den Webserver eines Automatisierungsgeräts. Dann wird auf dem abzuhörenden Rechner die ARP-Tabelle (Adress Resolution Protocol, damit werden MAC-Adressen den IP-Adressen im LAN zugeordnet) manipuliert. Letzteres erfolgt mittels Arpspoof vom Angriffsrechner aus. Mit einer solchen Vorgehensweise lässt sich die Kommunikation zwischen dem eingebetteten Webserver einer Automatisierungsbaugruppe und einem Benutzer-PC innerhalb des gleichen LANs abhören, aufzeichnen, manipulieren und auch über die Internetverbindung des PCs in alle Welt weiterleiten.

Bei einem Cross-Site-Scripting-Angriff (XSS-Angriff) versucht ein Webclient einem Server per Request ein Codefragment zu übermitteln. Falls der Webserver den Request nicht hinsichtlich der XSS-typischen Kriterien prüft, wird ausführbarer Schadcode entwede

Bei einem Cross-Site-Scripting-Angriff (XSS-Angriff) versucht ein Webclient einem Server per Request ein Codefragment zu übermitteln. Falls der Webserver den Request nicht hinsichtlich der XSS-typischen Kriterien prüft, wird ausführbarer Schadcode entwedeSSV Software

Dauerbaustelle XSS

Doch nicht nur mit Man-in-the-Middle-Attacken lassen sich Webserver aushorchen und ihre Daten verändern. Eine weitere verbreitete Attacke ist XSS. XSS ist die Abkürzung für Cross-Site Scripting. Gemeint ist damit eine Angriffsform, bei der einem HTTP(S)-Server innerhalb einer Anfrage (HTTP-Request) ein ausführbares Codefragment übermittelt wird, um mit diesem Code einen Speicherbereich des Servers zu infizieren (persistentes XSS) oder dafür zu sorgen, dass der Code in der Serverantwort (HTTP-Response) direkt an den Client zurückgeschickt wird (reflektierendes beziehungsweise nicht persistentes XSS). Im ersten Fall wird der Code zu einem späteren Zeitpunkt als Antwort auf eine Abfrage an den Client geschickt – durch einen Konfigurationsdaten-Eintrag. In beiden Fällen führt der Client – typischerweise ein Webbrowser – den Code aus.

Vielfach wird Javascript-Code für XSS-Attacken genutzt, da dieser Code auf praktisch jedem Client ausgeführt werden kann. Javascript-Code lässt sich zum Beispiel über Eingabe- oder Abfragefelder und den dazugehörenden Requests an den Server übermitteln. Mit einem solchen XSS-Angriff kann auf dem Client als Zielsystem beliebiger Schadcode zur Ausführung gebracht werden. Eine Schwachstelle für XSS ist in vielen Automatisierungsprodukten die webbasierte Konfigurationsschnittstelle. Sie fordert in der Regel zunächst einen Login mit Benutzername und Passwort. Durch die Anmeldung wird auf dem Clientsystem eine Session-ID erzeugt. Danach sind bis zur Abmeldung ohne weitere Passworteingabe die beim Login zugewiesenen Rechte nutzbar. Mithilfe eines entsprechend vorbereiteten XSS-Angriffs könnte nun die Session durch einen Schadcode missbraucht werden, um unzulässige Konfigurationseinstellungen vorzunehmen oder den Client mit einem anderen Server zu verbinden, ohne dass dem Bediener dies auffällt (Website Spoofing). Auf diese Art und Weise lassen sich zum Beispiel sicherheitsrelevante Informationen wie Passwörter oder Zertifikate abgreifen.

Der Schutz einer webbasierten Benutzeroberfläche durch eine Benutzername-Password-Kombination ist in der Praxis vielfach unzureichend. Eine bessere Zugriffssicherheit ist mit einem zusätzlichen Security-Dongle möglich, der erst nach einer erfolgreichen Ch

Der Schutz einer webbasierten Benutzeroberfläche durch eine Benutzername-Password-Kombination ist in der Praxis vielfach unzureichend. Eine bessere Zugriffssicherheit ist mit einem zusätzlichen Security-Dongle möglich, der erst nach einer erfolgreichen ChSSV Software

Um XSS-Angriffe auf Automatisierungsbaugruppen zu unterbinden, muss der jeweilige Server jeden eingehenden Request systematisch nach den XSS-typischen Zeichenfolgen durchsuchen und alle kritischen Sequenzen ausfiltern. Das gilt auch für alle Erweiterungen, die in Form von CGI-Modulen – das Common Gateway Interface ist ein standardisiertes Schnittstellenkonzept für Webserver-Erweiterungsmodule – oder sonstigen serverseitigen Skripten erstellt werden und die Antworten für Client-Systeme erzeugen. Darüber hinaus sollte alle Webschnittstellen einer Automatisierungskomponente mit professionellen Testwerkzeugen, zum Beispiel ZAP, durch entsprechend geschulte Fachkräfte geprüft werden.

In den USA betreibt die Regierung ein ICS-CERT (Industrial Control Security Computer Emergency Response Team). Es ist dem US Department of Homeland Security unterstellt und veröffentlicht fortlaufend Schwachstellen in Automatisierungsprodukten. Hier findet man auch etliche namhafte deutsche Hersteller, die mit den XSS-Schwachstellen in ihren Produkten aufgefallen sind. Das tatsächliche Ausmaß hinsichtlich existierender XSS-Sicherheitslücken in Automatisierungs-Webservern ist unbekannt. Man kann aber davon ausgehen, dass die meisten Systeme keinen ausreichenden Schutz gegen diese tückische Gefahr bieten. Lediglich Hersteller, die entsprechende Penetrationstests durchgeführt haben oder beim ICS-CERT schon aufgefallen sind, werden ihre Webschnittstellen entsprechend abgesichert haben.

Wer bist du wirklich?

Aufgrund der Gefahren durch Man-in-the-Middle- oder XSS-Angriffen sind nur durch Benutzername-Passwort-Kombinationen geschützte Weboberflächen in Automatisierungsbaugruppen aus Security-Sicht völlig unsicher und praktisch für jedermann zugänglich. Häufig werden für eine Baugruppe einfache Passwörter, zum Beispiel der Firmenname, oder auch die ab Werk vorgegebene Einstellung mit dem im Benutzerhandbuch dokumentierten – und somit für jeden zugänglichen – Benutzernamen und Passwort genutzt. Darüber hinaus lässt sich die HTTP-Kommunikation zwischen einem Webserver und Browser über einen Man-in-the-Middle-Angriff einfach mit kostenlosen, aber leitungsfähigen Werkzeugen abhören. Bei vielen Systemen werden Benutzername und Passwort im Klartext, oder Base64-kodiert über das LAN-Kabel übertragen, sodass ein Angreifer durch Abhören in den Besitz dieser Geheimnisse gelangen kann. Mit Werkzeugen, wie SSLstrip und den damit möglichen SSL-Stripping-Attacken kann ein Angreifer auch für eine HTTPS-Anmeldeseite mit eigentlich verschlüsselter Übertragung die Benutzername-Passwort-Kombinationen ausspähen.

Ein deutlich besserer Zugriffsschutz für Weboberflächen in Automatisierungsbaugruppen lässt sich mithilfe einer Zwei-Faktor-Authentifizierung realisieren. Bei dieser Authentifizierungsmethodik erfolgt der Identitätsnachweis eines Nutzers durch die Kombination zweier voneinander unabhängiger Komponenten (Faktoren). Dabei unterscheidet man zwischen: etwas, was der Nutzer besitzt (having something), zum Beispiel einem Dongle oder Token, etwas, was der Nutzer weiß (knowing something), beispielsweise eine Benutzername-Passwort-Kombinationen oder eine PIN und etwas, was als körperliches Charakteristikum untrennbar zum Nutzer gehört (being something), beispielsweise ein Fingerabdruck.

Ein recht wirkungsvoller Zugriffsschutz lässt sich zum Beispiel durch einen Security-Dongle mit Challenge-Response-Authentifizierung realisieren, der zunächst einmal mit einer Schnittstelle der Automatisierungskomponente verbunden werden muss. Dadurch wird die Weboberfläche überhaupt erst freigeschaltet, um die Benutzername-Passwort-Kombination einzugeben. Bei der Challenge-Response-Authentifizierung teilen sich beide Seiten – in diesem Fall die Automatisierungsbaugruppe und der Security-Dongle –einen Schlüssel. Dieser ist in der Regel durch einen Ab-Werk-Setup, in einem speziellen Speicherbereich hinterlegt. Der Schlüssel selbst wird niemals ausgelesen, über einen Übertragungskanal gesendet oder visualisiert. Nach dem Einstecken des Dongles wird eine einmalige Zufallszahl (Nonce) gebildet und als Challenge an den Dongle übertragen. Dieser ermittelt aus der Zufallszahl und dem hinterlegten Schlüssel über einen Algorithmus (Hashfunktion) einen digitalen Fingerabdruck. Der wird als Response vom Dongle an die Automatisierungsbaugruppe zurückgeschickt. Die kennt ebenfalls den Schlüssel und die Hashfunktion des Dongles. Somit kann auch die Automatisierungsbaugruppe den digitalen Fingerabdruck für die Challenge erzeugen und das Ergebnis mit der vom Dongle erhaltenen Response vergleichen. Sind beide Fingerabdrücke identisch, wird die Challenge-Response-Authentifizierung erfolgreich abgeschlossen. Nun kann der Nutzer die Benutzername-Passwort-Kombination eingeben.