Nun ist es also passiert: Erstmals wurde mit voller Absicht ein Safety-System in einer chemischen Anlage im Produktivbetrieb mit Schadsoftware angegriffen. Der Angriff wurde rechtzeitig erkannt, bevor Schaden angerichtet werden konnte. Kein Grund zur Entwarnung jedoch — erfahren Sie die Hintergründe.
Was ist passiert?
Ende 2017 bemerkte ein Betreiber einer chemischen Anlage — die New York Times vermutet, dass es sich um die Firma Sadara in Saudi-Arabien handelt — eine Notabschaltung eines Anlagenteils, ausgelöst von einer Triconex-Safety-Steuerung. Grund für die Notabschaltung war aber nicht das Über- oder Unterschreiten bestimmter sicherheitsrelevanter Prozessparameter, sondern eine Störung der Systemintegrität. Die Steuerung hatte automatisch erkannt, dass auf den redundanten Modulen nicht derselbe Code läuft und ist daraufhin richtigerweise in den Failsafe-Zustand gegangen.
Bei der Untersuchung des Vorfalls bekam der Betreiber den Verdacht, dass es sich um einen Cyber-Angriff handeln könnte, und beauftragte die US-amerkanische Firma FireEye mit einer Analyse. Bei dieser Analyse stellte sich heraus, dass der Verdacht begründet war. Einige technische Details wurden mittlerweile von FireEye und auch von Schneider Electric — Triconex gehört zu Schneider — veröffentlicht (siehe die Links am Ende des Textes).
Die Identität der Angreifer ist noch nicht bekannt. Anders als beispielsweise im Fall des Cyber-Angriffs auf Saudi Aramco gab es bislang keine Selbstbezichtigung einer Hacker-Gruppe.
Technische Hintergründe
Die Angreifer haben erfolgreich Schadcode auf die Triconex-Steuerungen gebracht, nachdem es ihnen gelungen war, die entsprechenden Engineering-Stationen zu kompromittieren. Dabei wurde der eher ungewöhnliche Weg gegangen, zunächst eine kompromittierte Firmware für die Steuerungen zu erstellen und diese dann auch (erfolgreich) auf die Steuerungen zu laden. Aufgabe der kompromittierten Firmware war, beliebige Schadmodule, die dann auf Sensorik und Aktorik wirken, nachladen zu können.
Ungewöhnlich ist dieser Weg deshalb, weil bei einem gut vorbereiteten Angriff nur ein einmaliges Laden von Schadcode in das User Memory der Steuerungen erforderlich gewesen wäre, wozu es keiner Firmwaremodifikation bedurft hätte. Den Angreifern war diese Tatsache entweder nicht hinreichend bewusst, oder sie wollten sich aus anderen Gründen eine Persistenz auf den Steuerungen verschaffen — mit der Option, über einen längeren Zeitraum hinweg unterschiedliche Schadmodule auf die Steuerungen zu laden und zur Ausführung zu bringen.
Zur Infiltration wurde ein legitimer Fernwartungszugang genutzt, für den sich die Angreifer die Zugangsdaten beschafft hatten. Die Ausbreitung in den Netzen des Opfers erfolgte dann durch gängiges Hacker-Handwerkzeug wie Metasploit, Mimikatz, Nmap u.a. Nichts besonderes. Die größte technische “Leistung” besteht bei diesem Angriff darin, eine modifizierte Firmware für die Triconex-Steuerungen zu entwickeln. Eine Besonderheit dieses Falls besteht darin, dass die Angreifer offenkundig auf dem Zielsystem experimentiert haben und dabei auch recht krude Skripts verwendeten, die mehr oder weniger offensichtliche Programmierfehler enthalten.
Erkenntnisse
- Cyber-Angreifer machen vor der Safety nicht halt. Personenschäden werden heute nicht nur in Kauf genommen, sondern absichtlich herbeigeführt.
- Engineering-Stationen bleiben die Systeme mit der höchsten Kritikalität. Denken Sie insbesondere auch an mobile Engineering-Stationen (Laptops / PGs).
- Auch hier (ähnlich wie beim Cyber-Angriff 2015 auf das ukrainische Stromnetz) wurde ein legitimer Fernwartungszugang kompromittiert. Ihre Fernwartungszugänge sollten niemals in kritischen Systemen wie beispielsweise Safety enden können.
- Die Angreifer hatten offenkundig keine wirklich tiefgreifenden Kenntnisse im Bereich Anlagensicherheit und sahen sich deshalb genötigt, auf dem Zielsystem zu experimentieren, und das nicht einmal besonders professionell. Beunruhigen muss, dass mittlerweile Hacker aus dem IT-Umfeld nicht vor Safety-Systemen halt machen.
- Die von Schneider Electric in den Raum gestellte Urheberschaft einer potenten staatlichen Angreifers erscheint unwahrscheinlich, da die Ausführung des Angriffs dafür zu unprofessionell ist. Wahrscheinlicher ist eine Hacker-Gruppe aus der IT-Szene, die möglicherweise staatlich gesponsert wurde.
- Die Cyber-Sicherheit beim Opfer war in eklatanter Weise unsachgemäß. Auf die sachgerechte Benutzung des Schlüsselschalters der Steuerung verzichtete der Betreiber. Selbst grobe Verletzungen der Systemintegrität (Aufkopieren einer neuen Datei “INJECT.BIN” auf das Engineering-System der Safety-Steuerungen) blieben unbemerkt. Auch das extensive Experimentieren der Angreifer unter Zuhilfenahme von Scripten und Tools wie Nmap hätte dem Opfer auffallen müssen. Die Angreifer machten so viel “Lärm”, dass man, bildlich gesprochen, schon Ohrenstöpsel tragen musste, um nichts mitzubekommen.
Gegenmaßnahmen
Die wirksamsten Gegenmaßnahmen, die den Angriff verhindert hätten, sind:
- Sachgerechte Verwendung des Schlüsselschalters der Safety-SPS (Projektiermöglichkeit nur dann, wenn eine Projektierung beabsichtigt ist)
- Vernünftige Netzwerksegmentierung: Keine Zugriffsmöglichkeit per Fernwartung auf die Engineering-Stationen
- Application Whitelisting auf den Engineering-Stationen
Wir empfehlen Ihnen, daraufhin Ihre Security-Architektur zu überprüfen. Sprechen Sie uns bei weitergehenden Fragen an.
Links
Analyse von FireEye (Blog Post)
Video: Analyse des Angriffs durch FireEye/Mandiant auf der S4-Konferenz
Video: Analyse des Angriffs durch Schneider Electric auf der S4-Konferenz
Video: Ralph Langner, Zach Tudor und Dale Peterson diskutieren den Angriff auf der S4-Konferenz