Die Digitalisierung durchdringt alles: Früher isolierte Systeme werden vernetzt und gleichzeitig werden Angriffe auf IT-Systeme zu einer immer realeren und schwerwiegenderen Bedrohung.

Also sollte man davon am besten die Finger lassen, lieber weiterhin auf isolierte und vollständig abgeschottete Systeme setzen und sie durch geheime, eigenentwickelte Sicherheitsmaßnahmen so schützen, dass niemand sie (unbefugt) nutzen kann? „Digitalisierung“ ist auch nur so eine Modeerscheinung! Dann wäre man Unterlasser und nicht Unternehmer. Aber IT-Security wird von vielen Entwicklern und Betreibern als lästigen Stolperstein gesehen und steht einer schnellen Lösung oft im Weg. Es ist jedoch schwierig bis unmöglich, IT-Sicherheit nachträglich in ein fertiges Produkt zu integrieren.
Dabei sollte IT-Sicherheit – als früher Bestandteil der Entwicklung – als Enabler gesehen werden und ein neues digitales Geschäftsmodell sogar erst ermöglichen. Denn ohne eine wirksame Absicherung gegen eine Vielzahl von Angriffen wird eine möglicherweise clevere Geschäftsidee sabotiert, kompromittiert, kopiert und abgeschöpft. Hierfür gibt es erprobte und etablierte Verfahren, die man einfach nur anwenden muss.
Während verschiedener Projekte ist immer wieder aufgefallen, dass dies vielfach immer noch nicht umgesetzt wird. So fanden sich in bisher allen von Autor untersuchten IT-Systemen vom Smartphone über vernetzte KFZ bis hin zur Industriesteuerungsanlage eklatante Sicherheitslücken, die auf Unkenntnis und Ignoranz der Entwickler und/oder falschen unternehmerischen Entscheidungen zurückzuführen sind.

Ein Beispiel aus der Welt der Industriesteuerungsanlage (OT)
Zur Durchführung eines Penetration-Tests an einem (zugekauften) Steuerungscomputers wurde von einem Hersteller von Gas-Misch-Anlagen ein fertig konfiguriertes Embedded System zur Verfügung gestellt. Alle Versuche, das System wirksam zu attackieren und Informationen offenzulegen, scheiterten zunächst, u. a. auch, weil der Pen-Tester einfach Pech hatte. Er war beim Erraten der Benutzerkennung um einen Buchstaben haarscharf am Ziel vorbeigeschossen und so förderte die statische Analyse zunächst keine Benutzerkennungen zu Tage. Sollten die Passwörter tatsächlich sauber gehashed (also verschlüsselt) abgelegt worden sein?

Gefährliches Halbwissen
Zunächst fand der Tester trotz offenem HTTP-Port (80) auf dem Zielsystem keine Möglichkeit, mit einer Brute-Force-Attacke einen Zugang zur Web-Oberfläche zu erhalten. Das lag – wie sich später herausstellte – daran, dass der Mitarbeiter des Herstellers des Steuerungscomputers den HTTP-Zugang gar nicht erst konfiguriert bzw. freigeschaltet hatte. Er mache das grundsätzlich nicht, „weil das ja unsicher ist“. Gut, aber was nützt diese „Sicherheitsmaßnahme“, wenn er gleichzeitig einen unverschlüsselten FTP-Zugang bereitstellt, der u. a. zum Beschreiben der Steuerung mit neuer Firmware geeignet ist? Und warum nutzt er dann ein Trivialpasswort von lediglich drei bzw. vier Stellen, bei dem dieses und die Kennung auch noch vom Firmennamen ableitbar sind?
Und was ist, wenn die Kunden dann doch einen Web-Zugang zum System haben möchten? O-Ton: „Stimmt, die Anfragen gab es schon, aber das konnten wir bisher immer noch abwenden“. Die Frage ist: Wie lange kann man den nicht überraschenden Kundenwunsch ignorieren? Digitalisierung und Industrie 4.0 schreien gerade danach, Systeme nicht nur zu vernetzen, sondern die Daten auch an vielen Stellen verfügbar zu machen.

„Ohne eine wirksame Absicherunggegen eine Vielzahl von
Angriffen wird eine möglicherweise clevere Geschäftsidee
sabotiert, kompromittiert, kopiert und abgeschöpft."
 

Hausaufgaben nicht gemacht
Aber auch der Hersteller des Steuerungscomputers hat gepatzt. Er bietet an der Web-Schnittstelle die sogenannte Digest Access Authentication an. Das ist besser als die simplere, aber komplett unverschlüsselte Basic Access Authentication-Methode, aber leider nur die halbe Miete. Beim Digest Access Authentication Verfahren werden Benutzername und Passwort nicht im Klartext, sondern mit zusätzlichen Informationen und Zählern gehashed übertragen. Damit kann man weder das Passwort mitlesen noch das Authentifizierungspaket für eine sogenannte Replay-Attacke später wiederverwenden. Der Rest der Übertragung ist jedoch komplett unverschlüsselt. Das bedeutet, dass ein Angreifer zwar nicht das Login übernehmen, aber die nachfolgende Kommunikation mitlesen und verändern kann. Je nach Geschäftsmodell greift er nun Produktionsdaten ab (Spionage) oder er verändert diese, um die Produktion zu stören (Erpressung, Wettbewerbsvorteil etc.).

Die Lösung lag so nah: Verschlüsselung
Hätte der Entwickler noch ein paar Minuten weiter gegoogelt, dann hätte er herausgefunden, dass die Verschlüsselung des gesamten Datenverkehrs mit TLS die bessere Idee gewesen wäre. Die ist nach heutigem Stand sicher gegen Mitlesen und Verändern der Kommunikation. Natürlich kann man auch hier noch Fehler machen. TLS wurde aus dem SSL-Standard weiterentwickelt und existiert derzeit in den Versionen 1.0, 1.1, 1.2 und 1.3. Während SSL als veraltet gilt und gar nicht mehr eingesetzt werden sollte, muss man auch bei TLS darauf achten, dass man die derzeit (2020) aktuellen Versionen 1.2 und 1.3 einsetzt.
Darüber hinaus sollten Betreiber eines mit TLS gesicherten Servers auch dafür achten, dass die zur Verschlüsslung eingesetzten digitalen Zertifikate vertrauenswürdig sind (Chain of Trust) und der Client (Webbrowser bzw. APP) eine Chance hat, sich von der Validität des Zertifikats auch überzeugen zu können. Denn eine Man-in-the-Middle-Attacke ist auch bei verschlüsselter Kommunikation möglich. Nämlich dann, wenn es dem Angreifer gelingt, dem Opfer ein Fake-Zertifikat als das echte vorzugaukeln. Dann verschlüsselt das Opfer auf der Strecke zwischen seinem Endgerät und dem Angreifer mit dem Fake-Zertifikat. Der Angreifer entschlüsselt nun die Nachricht, da er ja zu dem gefälschten Zertifikat den geheimen, privaten Schlüssel besitzt und liest die Daten aus. Dann leitet er die Datenpakete mit dem echten Zertifikat des Zielservers verschlüsselt an die eigentlich vom Opfer angesprochene Adresse (ggf. modifiziert) weiter. Besonders perfide wird so ein Angriff, wenn dem Opfer vorgespielt wird, dass es mit dem echten Server kommuniziert und passende Bestätigungen zurückgespielt werden. Ein wirksamer Schutz dagegen ist z. B. das sogenannte Zertifikats-Pinning, bei dem Endgerät (App) bereits bei deren Auslieferung (Entwicklung) fest verdrahtet mitgeteilt wird, wie das echte Server-Zertifikat auszusehen hat (Trust-On-First-Use – TOFU).

Dann eben per FTP – oder besser SFTP
Um noch einmal zu der vermeintlichen Sicherheitsentscheidung zum HTTP-Verzicht zurückzukommen: So etwas ist unlogisch, wenn man dennoch unverschlüsseltes FTP anbietet, obwohl es auch hier eine TLS-verschlüsselte Variante gibt: Secure FTP (SFTP).
So war es dann für den Pen-­Tester auch einfach, u. a. durch eine Man-in-the-Middle-Attacke mit Wireshark das FTP-Login des Bedieners zu ermitteln. So war es nicht nur möglich, die Zugriffe des Operators mitzulesen, sondern sich auch direkt selbst mit diesen Credentials einloggen.

Unverschlüsselte Speicherung von Passwörtern im Code
Aber es wird noch kritischer: Bei der statischen Analyse des unverschlüsselt vorliegenden Binärcodes (Firmware) des Steuerungscomputers hatte der Pen-Tester die Ablage Kennwörtern als Klartext noch übersehen. Das lag daran, dass Benutzernamen und Passwörter so kurz und unauffällig (Benutzer XXX = Kurzbezeichnung des Herstellers und Passwort „100“ und „200“) waren. Mit dem späteren Wissen der mitgelesenen Kennungen fanden sich diese aber auf einfachste Weise. Hier wäre es sogar möglich gewesen, die Passwörter zu ändern (z. B. auf „999“) und nach einem erneuten Hochladen per FTP die legitimierten User auszusperren.
Den Betreiber rettete neben der Prüfsumme, die nicht mehr stimmte, auch die Tatsache, dass man von außen den Prozess zum Nachladen des per FTP hochgeladenen Codes nicht so einfach initiieren konnte.
Das ist der Grund, warum viele Angriffe in der Praxis oft nicht funktionieren. Irgendwo in der Kette ist ein Bruch, ein Fehler oder der Hacker hatte einfach Pech. Vertrauen sollte man auf dieses Pech nicht.
So zeigte sich auch im Fall einer willkürlich ausgewählten und aktuell massenhaft verwendeten Industriesteuerung das gleiche Bild wie schon bei anderen Pen-Tests: Standardverfahren wie Digitales Verschlüsseln, Signieren und Hashen werden nicht oder nicht konsequent eingesetzt. Dabei sind diese Verfahren meist ohne nennenswerte Mehrkosten verfügbar – wenn man die Entscheidung zu deren Einsatz früh genug trifft. Nachher wird es dann teurer…

ZUR PERSON
Thomas Käfer, ist mit seinem IT-Systemhaus seit 1990 selbstständig in der IT tätig. Der Diplom­ingenieur arbeitet seit 2002 als Sachverständiger für Systeme und Anwendungen der Informationsverarbeitung (seit 2006 öffentlich bestellt), als IT-Consultant und Fachautor. IT-Sicherheit, Datenschutz und Digitale Forensik stehen dabei im Mittelpunkt seiner Arbeit. Seit 2019 arbeitet er mit der Weyer-Gruppe zusammen, um Anlagenbetreiber und -hersteller für das Thema der Cyber Security zu sensibilisieren und praktische Lösungsansätze zu entwickeln.

Partnerschaft
Seit 2019 arbeitet die Weyer-Gruppe – eine lieferantenunabhängige Gruppe von Ingenieurbüros für verfahrenstechnische Anlagenplanung und Anlagensicherheit – mit Thomas Käfer zusammen und erweitert so ihre Betrachtungen der funktionalen Sicherheit von Anlagen und Maschinen um die Cyber-Security-Komponente. Neben Schulungen und Beratung bietet die Weyer-Gruppe ein Kolloquium zum Thema an, das am 18. Juni 2020 in Düren stattfindet.
www.weyer-gruppe.com