Wovon Angreifer auf kritische Infrastrukturen träumen
Industroyer 2 und Incontroller / Pipedream: Versuch einer Einordnung
Von fünf auf sieben: Innerhalb nur eines Monats sind im Frühjahr 2022, mitten in den Wirren des Kriegs in der Ukraine, zwei neue, komplexe Angriffe (beziehungsweise deren Vorbereitung) auf kritische Infrastrukturen bekannt geworden, genauer gesagt auf die Automatisierungssysteme, die kritische Infrastrukturen am Laufen halten (im Folgenden kurz “ICS” — Industrial Control Systems). Zuerst Industroyer 2, eingesetzt für einen Angriff auf die ukrainische Stromversorgung, dann Incontroller/Pipedream, eine beeindruckendes Stück Schadsoftware, um kritischen Infrastrukturen zu schaden — das aber wohl noch auf seinen Einsatz wartet. Wir hangeln uns jeweils anhand von fünf Fragen durch die verschiedenen Fälle, um den Überblick zu behalten:
- Wie wurde die Schadsoftware entdeckt?
- Was waren die Auswirkungen?
- Was ist das Ziel der Schadsoftware und wer steckt dahinter?
- Wie funktioniert die Schadsoftware und wie funktioniert ein Angriff mit ihr?
- Und jetzt?
Teil 1 — Industroyer 2: Gerade noch mal gut gegangen, aber Schutzschilde hoch!
Industroyer 2? Was war denn noch mal Industroyer? Hieß das nicht Crashoverride? Und was hat das mit Incontroller und Pipedream zu tun?
Wie wurde Industroyer 2 entdeckt?
Ganz genau ist das öffentlich nicht bekannt. Aber gemäß der Neuen Zürcher Zeitung haben die ukrainischen Behörden Anfang April einen Hinweis erhalten, woraufhin die slowakische Security-Firma ESET, das ukrainische CERT (CERT-UA) und Microsoft gemeinsam tätig wurden.
Was waren die Auswirkungen?
Bekannt sind keine. ESET, CERT-UA und Microsoft haben den Angriff, der wohl für den 8. April geplant war, vereiteln können.
Was ist das Ziel der Schadsoftware und wer steckt dahinter?
Der Angriff galt einem Umspannwerk eines ukrainischen Energieversorgers. Der Plan war gemäß der Analyse von ESET, die Stromversorgung für einen Teil der Ukraine zu unterbrechen. Das wäre nicht das erste Mal: Bereits 2015 und 2016 kam es in der Ukraine zu Stromausfällen durch Cyber-Angriffe, die der russischen Hackergruppe Sandworm zugeschrieben werden. Sandworm gehört zum russischen Militärgeheimdienst GRU. Der Angriff im Dezember 2016 erfolgte mit der Malware Industroyer. Das Kofferwort aus “Industry” und “destroy” hat damals ebenfalls ESET geprägt, die damals mit der Reaktion auf den Vorfall (Incident Response) betraut waren.
Die jetzige Schadsoftware kann gemäß der ESET-Analysen [1] als Nachfolger von Industroyer angesehen werden, ergo die Bezeichnung Industroyer 2. Es ist also sehr wahrscheinlich, dass auch Industroyer 2 Sandworm zuzurechnen ist.
“Crashoverride” ist übrigens die Bezeichnung der US-amerikanischen Threat-Intelligence-Firma Dragos — sie meint aber exakt dieselbe Schadsoftware wie Industroyer. Es ist eine Marotte von Security-Firmen, dass im Kampf um die Deutungshoheit und die “erste Fahne auf dem Mond” jeder seinen eigenen Namen für neue Malware erfindet.
Wie funktioniert die Schadsoftware selbst und wie funktionert ein Angriff mit ihr?
Die Analysen sind noch nicht fertig und werden dadurch erschwert, dass Industroyer gemeinsam mit einem “Wiper” eingesetzt wurde — also einem Stück Software, das effizient dafür sorgt, dass Systeme nicht mehr gebootet werden können. Die Wiper-Software heißt “Caddy Wiper” und ist bekannt aus der Serie von Wiper-Angriffen auf ukrainische Ziele, die den Beginn des russischen Angriffskriegs begleitet haben (siehe Hard Hats-Briefing aus dem März diesen Jahres).
Wie genau die Angreifer ins Netzwerk kamen, ist noch nicht bekannt. Wohl aber, dass sie sich mittels eines Wurms verbreitet, also einer Software, die automatisch nach potenziellen weiteren Zielen im Netzwerk sucht und versucht, darauf zuzugreifen. Die Wiper-Software wurde mutmaßlich via Active Directory verbreitet, und ESET vermutet, dass dem Angreifer dafür vorab Zugangsdaten bekannt waren.
Industroyer 2 selbst ist eine ausführbare Windows-Datei, die mittels des 104er-Protokolls mit Zielsystemen kommunizierte. “IEC 104” (genau: IEC 60870–5–104:2006) ist ein in der Energieversorgung übliches Protokolls für die Kommunikation zwischen Automatisierungskomponenten. Die Schadsoftware ist, so ESET, in hohem Maße konfigurierbar und was sie genau mit ihren Zielsystemen macht, ist noch unklar — aber das Ziel ist wohl die Unterbrechung der Stromversorgung für einen Teil der Ukraine. Für den Aggressor eines Angriffskriegs ist das selbstverständlich ein reizvolles Ziel.
Und jetzt?
Tja. Auf Angriffe wie diese hat die Fachwelt seit Wochen mit Sorge gewartet; es gab sogar Stimmen, die eine “überraschende Ruhe” im ukrainischen Cyberraum (zumindest für kritische Infrastrukturen) feststellten. Ich weiß aus einigen Gesprächen, dass Betreiber kritischer Infrastrukturen, vor allem Energieversorger, in diesen Tagen besonders wachsam sind. Griffig fomuliert haben das (natürlich) die US-Amerikaner: Die US-amerikanische Behörde CISA macht mit der Kampagne “shields up” (deutsch: “Schutzschilde hoch” auf die gesteigerte Bedrohungslage aufmerksam. Die dort beschriebenen Maßnahmen sind natürlich auch für deutsche Organisationen sinnvoll — und natürlich nicht neu, wenn man sich mit ICS-Security beschäftigt.
Für Industroyer 2 hat das ukrainische CERT-UA Indicators of Compromise (IoCs) veröffentlicht (in der Landessprache), mit denen man prüfen kann, ob Systeme mit der Industroyer-Malware infiziert sind. Das funktioniert natürlich aber nur, solange Sandworm seine Malware nicht weiter verändert — unwahrscheinlich.
Für mehr Details gibt es den ständig aktualisierten Blog von ESET (auf englisch) [1]. Gute Artikel auf deutsch sind rar gesät, aber bei der NZZ [2] gibt es einen vernünftigen, wenn auch knappen Text.
Teil 2 — Incontroller / Pipedream: Neuer Werkzeugkasten für Angriffe auf Automatisierungssysteme (ICS)
Nun, da wir gerade so schön warmgelaufen sind, sehen wir uns dann auch gleich ICS-Schadsoftware Numero Sieben an. Die fünf wichtigen Fragen kennen Sie ja schon — also los. Die Informationen stammen, sofern nicht anders vermerkt, aus den Veröffentlichungen der Security-Firmen Dragos [3] und Mandiant [4], die die Schadsoftware untersucht haben (und — Sie ahnen es schon — ihr jeder einen eigenen Namen verpasst haben: Incontroller ist der Mandiant-Name, Pipedream der Dragos-Name). In der deutschsprachigen Presse ist auch dieses Thema nicht so recht angekommen, abgesehen von einem schmalbrüstigen Artikel bei heise.
Wie wurde Incontroller / Pipedream entdeckt?
Der Fall ist insofern anders gelagert als bei Industroyer, dass die Schadsoftware entdeckt und analysiert wurde, obwohl sie noch gar nicht in einem Angriff verwendet worden ist — oder zumindest wurde der destruktive Teil des Angriffs noch nicht begonnen. (“pipe dream” heißt auf deutsch “Wunschtraum”). Wie kann man Malware finden, die noch nicht eingesetzt wurde? Darüber schweigen sich die Blogs der beteiligten Firmen Mandiant und Dragos aus. Kein Wunder: Man möchte Angreifern natürlich nicht offenlegen, wie man ihnen auf die Schliche kam.
Ohne Frage kann die Entdeckung aber als Erfolg von Threat Intelligence verbucht werden — das Brot-und-Butter-Geschäft von Dragos, das im Beobachten von Anzeichen für Cyberangriffe und Malware in Kundennetzwerken besteht. Es ist die erste ICS-spezifische Malware, die vor einem tatsächlichen Angriff identifiziert wurde. “We’re actually a step ahead of the adversary” verkündete Dragos’ CEO Robert M. Lee daher auch stolz auf Twitter. Die Freude ist berechtigt, allerdings: Wenn wir uns weiter unten anschauen, was wir zur Verteidigung jetzt mit diesem hart erarbeiteten Wissensvorsprung tun können, ist das ein Dämpfer.
Nun aber erst einmal zu den Details:
Was waren die Auswirkungen?
Bislang sind keine bekannt. Sowohl Dragos als auch Mandiant halten es aber für wahrscheinlich, dass sich das ändert. Klar — wieso sollten Angreifer sich die Mühe machen, ein so aufwendiges Werkzeug zu entwickeln, und es dann nicht einsetzen?
Das BSI schreibt dazu “Der modulare Aufbau der einzelnen Tools legt nahe, dass die Angreifergruppe diese Tools über einen längeren Zeitraum einsetzen möchte. Durch die Modularität sinkt der Aufwand, die Tools für andere Geräte nutzbar zu machen. Durch die Implementierung des weit verbreiteten Protokolls Modbus und von CODESYS kann nicht ausgeschlossen werden, dass andere Geräte, welche eine dieser Technologien einsetzen, ebenfalls angreifbar sind.”
Was ist das Ziel der Schadsoftware und wer steckt dahinter?
Die Angreifergruppe hinter dem Schadcode wird von Dragos “Chervonite” genannt. Wer dahinter steht, ist nicht bekannt, aber auf Basis der entwickelten Schadsoftware charakterisieren die Dragos-Researcher die Angreifergruppe als kompetent in Softwareentwicklung, kompetent in ICS-Spezifika wie industriellen Protokollen, und außerdem gut mit Ressourcen ausgestattet. Kurz: Das riecht nach einer staatlich geförderten Gruppe.
Mandiant vermutet Russland hinter der Schadsoftware, allerdings nicht aufgrund von Indizien in der Software selbst, sondern aufgrund der Historie russischer Cyberangriffe auf kritische Infrastrukturen und der offensichtlichen geopolitischen Lage. Dragos macht dazu keine Aussage.
Während das genaue Ziel von Incontroller/Pipedream nicht bekannt ist, kann man recht sicher sagen, dass industrielle Prozesse damit manipuliert werden sollen — in welchem industriellen Sektor und Land auch immer. Wenn man, wie Mandiant, Russland als Urheber vermutet, liegt die Schlussfolgerung nahe, dass die Ukraine oder einer ihrer Unterstützer, etwa die NATO-Staaten, im Fadenkreuz sind. Der CISA-Report warnt “vor allem den Energiesektor”.
Wie funktioniert die Schadsoftware selbst und wie funktionert ein Angriff mit ihr?
Incontroller / Pipedream kann man guten Gewissens als ganzen Werkzeugkasten für ICS-Angreifer bezeichnen. Eindrucksvolle Veranschaulichung: Die Software kann 38% der im MITRE ATT&CK for ICS Framework aufgeführten Angriffstechniken ausführen, wie Dragos schreibt. Darunter: Weitgehender Remote-Zugriff auf Schneider Electric-Steuerungen, Omron-Steuerungen und CoDeSyS-basierte Steuerungen sowie OPC-UA-Server. Was man damit anstellen könnte? Passworte erraten, die Steuerung mit Denial-of-Service-Angriffen lahmlegen, weiteren Schadcode auf der Steuerung nachinstallieren, den Betriebsmodus von Steuerungen ändern, den Arbeitsspeicher der Steuerungen löschen,….
Sie sehen: Ein gut bestückter Werkzeugkasten. Sowohl Dragos als auch Mandiant teilen die Schadsoftware in mehrere Untermodule auf (und benennen sie selbstverständlich verschieden).
Interessant, Besorgnis erregend und gleichzeitig typisch für ICS-Security ist, dass die Incontroller / Pipedream keine Schwachstellen ausnutzt (bis auf eine recht unspektakuläre Ausnahme, CVE-2020–15368 für einen Motherboard-Treiber der taiwanesischen Firma ASRock). Es werden stattdessen intendierte, bekannte Funktionen in den Zielsystemen verwendet, die also “insecure by design” sind. In anderen Worten: Was die Schadsoftware nutzt, sind durchaus “not bugs, but features” — nur leider eben mit “dual use”. In vielen Fällen beschleicht einen das Gefühl, die Schadsoftware ist eigentlich “nur” eine effiziente (?) Kombination mehrerer Engineering-Tools.
Die vorrangig betroffenen Hersteller Schneider und Omron haben also keine Fehler gemacht — zumindest keine, die nicht absolut branchenüblich sind, weil Security eben einfach lange kein Entwicklungskriterium im Design von Steuerungen war (und häufig immer noch nicht ist).
Die Schadsoftware hat auch einen Supply-Chain-Aspekt. Eine Schlüsselkomponente der Schadsoftware nutzt nämlich CoDeSyS, eine Laufzeitumgebung, die von vielen SPSen unterschiedlicher Hersteller verwendet wird und für ihre schwache IT-Sicherheit bekannt ist.
Kurz: Es hat sich nun eben mal eine sehr versierte Angreifergruppe mit einigem Eifer daran gemacht, die schon lange bekannten Security-Probleme in ICS-Komponenten zu nutzen. Sowohl Mandiant als auch Dragos vergleichen Incontroller / Pipedream hinsichtlich Komplexität und möglicher Auswirkung mit Triton, Industroyer und Stuxnet.
Und jetzt?
Das ist dann wohl das zweite “tja” in diesem Text.
Auch hier könnte man erst mal sagen: Gerade noch mal gut gegangen. Immerhin wissen wir nun wieder ein wenig mehr über Angreifer und können uns damit sowohl vorbeugend, als auch im Monitoring und der Reaktion auf Vorfälle, genauer darauf ausrichten.
Dabei gibt es allerdings zwei Probleme: Erstens ist ja bis auf eine recht unbedeutende Ausnahme keine Schwachstelle beteiligt (siehe oben), also kann man auch keine Schwachstelle patchen. Zweitens ist das Schadcode-Framework so vielseitig, dass man nicht genau vorhersagen kann, was und wie damit angegriffen wird, und damit auch schlecht, wie man sich zielgerichtet verteidigt.
Einen Hinweis darauf, was angegriffen werden soll, geben die Zielsysteme, auf die die Schadsoftware offensichtlich ausgelegt ist. Denn Incontroller/Pipedream ist vielseitig anpassbar — die Tatsache, dass diese Anpassung für sehr spezifische Technik bereits stattgefunden hat, spricht dafür, dass ein Ziel bereits eingegrenzt wurde. Es ist daher durchaus sinnvoll, zu prüfen, ob die betroffenen Schneider- oder Omron-Produkte (siehe CISA-Alert) sowie OPC UA in der eigenen Organisation im Einsatz sind — und falls ja, die entsprechenden konkreten Empfehlungen umzusetzen.
Für alle anderen Fälle lesen sich die Maßnahmenempfehlungen erwartungsgemäß generisch.
Sowohl die US-amerikanische Cybersecurity & Infrastructure Security Agency (CISA; gemeinsam mit NSA, FBI und Energieministerium) [5] als auch das deutsche Bundesamt für Sicherheit in der Informationstechnik (BSI) [6] und die Allianz für Cybersicherheit haben Warnungen mit Maßnahmenempfehlungen herausgegeben. Das BSI attestiert industriellen Automatisierungssystemen eine erhöhte Bedrohungslage (Stufe 2 von 4). Schneider Electric hat ein Security Bulletin veröffentlicht [7], in dem die betroffenen Schneider-Produkte und Maßnahmen dafür benannt sind, CoDeSyS hat für seine Produkte dasselbe getan [8]. Für die Ausnutzung der ASRock-Schwachstelle sind YARA-Regeln zur Erkennung verfügbar.
Ein Destillat der Empfehlungen:
- Gegen unauthorisierten Fernzugriff hilft Multifaktorauthenfizierung.
- Gegen Brute-Force-Angriffe auf Paswörter helfen komplexere Passwörter (und das Ändern von Standardpasswörtern).
- Die von Incontroller/Pipedream verwendeten Ports (UDP/1740–1743,
TCP/1105, and TCP/11740) zu sperren, kann nicht schaden — auch wenn zukünftige Änderungen natürlich auch die verwendten Ports ändern können. - Wenn die Angreifer einmal drin sind, hilft Netzsegmentierung, vor allem an der Grenze zwischen IT (häufigeres Einfallstor) und ICS und für alle besonders vulnerablen Systeme (Safety!)
- Gegen Angriffe, von denen man weder weiß wie, wann, noch wo sie auftreten, helfen eigentlich nur Härtung zur Reduzierung möglicher Angriffspunkte (konkrete Maßnahmenn für die betroffenen Produkte folgen) und Monitoring auf Anomalien und Schadsoftware.
- Weil Incontroller/Pipedream auch Wurm-Fähigkeiten hat, sich also von Gerät zu Gerät weiterbewegen kann, ist dabei Monitoring nicht nur des Datenverkehrs über Netzwerkgrenzen, sondern auch der Kommunikation innerhalb der Netze wichtig — vor allem unübliche Kommunikation mit SPSen.
- Idealerweise kann die Monitoring-Lösung ICS-Protokolle parsen, damit sie auch versteht, welche Inhalte ausgetauscht werden und nicht auf Metadaten limitiert ist.
- Auch besondere Wachsamkeit gegenüber Incontroller/Pipedream-Vorgehensweisen schadet nicht: Nachladen ungewöhnlicher Treiber, Anzeichen für Denial-of-Service-Angriffe wie ungewöhnlich lange Reaktionszeiten oder plötzliche Neustarts, Kommunikation mit Steuerungen von unüblichen Geräten,
- Wenn gar nichts geholfen hat, helfen nur noch ein guter Incident-Response-Plan, Offline-Backups und vorhandene Ersatzteile.
Sie sehen schon: Auch hier kann man wieder in etwa so zusammenfassen: Spezifisch kann man wenig tun, aber “shields up”! Das ist übrigens nicht ausschließlich eine schlechte Nachricht. Ist es nicht viel besser, wenn die guten, alten zeitlosen ICS-Security-Basics auch gegen so fortgeschrittene, spezifische Angriffe helfen, als wenn Sie ständig mit neuartigen Maßnahmen reagieren müssten?
Incontroller/Pipedream ist auch ein aktuelles Beispiel dafür, warum Patchen in der ICS nicht die oberste Priorität hat: Verwendet der Angriff keine Schwachstelle, hilft auch kein Patch. Auch das ist eher eine gute Nachricht: Denn Patchen ist immer reaktiv und damit hektisch, nicht planbar, tendenziell immer “zu spät”, erfordert ständiges Monitoren von Schwachstellen und ist in der ICS sowieso oft nicht machbar.
Sind wir jetzt wirklich “one step ahead of the adversary” und was bringt uns das?
Ja, gute Frage. Natürlich empfehlen Mandiant und Dragos über ihre frei verfügbaren Reports und die oben beschriebenen Maßnahmen hinaus auch ihre Threat Intelligence- und Threat Hunting-Dienstleistungen, und Dragos auch das eigene Tool, das mittels Threat Intelligence Angriffe erkennt. Die Hoffnung: Jetzt, da wir die Bedrohung kennen, können wir sie erkennen, bevor sie zuschlägt.
Wirklich? Ron Fabela geht dem Mehrwert von Threat Intelligence für ICS in seinem lesenswerten Blog “Why Intelligence Based Detections in ICS Fail” auf den Grund. Zitat: “The intelligence data derived from existing ICS attacks/malware do not scale or apply outside their target. Stuxnet/Triton/Industroyer researched and documented at that moment in time will never resurface exactly elsewhere (and have not to date).”
Es helfe sehr wohl, zu wissen, dass es Angreife auf ICS gebe, und wie solche Angreifer vorgingen, schreibt Ron. Aber um darauf basierend wirklich Angriffe detektieren zu können, seien die Anlagen zu verschieden, und die Angriffe zu selten und zu individuell zugeschnitten.
Also: Threat Intelligence für ICS ist wichtig für das Verständnis von generellen Vorgehensweisen, aber für die eigene, individuelle Verteidigung fährt man besser damit, seine eigenen Systeme zu kennen, zu beobachten und resilient zu machen, oder in Rons Worten: “While industrial threat intelligence may inspire, operations-based intelligence empowers. […] For ICS, it’s vitally important to have a solid understanding and control of the single most effective intelligence generating environment you have: your own control system. To put it another way: No one knows your environment better than you and your operators.”
Niemand kennt Ihre Anlagen besser als Sie und Ihre Anlagenfahrer: Mit diesem schönen letzten Satz entlasse ich Sie gern in Ihre individuelle “shields-up”-Strategiefindung. Sorgen Sie dafür, dass er wahr bleibt, dann sind Sie auf einem guten Weg.
Quellen:
[1] ESET-Blog zu Industroyer 2
[2] NZZ-Artikel zu Industroyer 2
[3] Dragos-Whitepaper zu Pipedream
[4] Mandiant-Blog zu Incontroller
[5] CISA-Alert zu Incontroller / Pipedream
[4] BSI-Warnung zu Incontroller / Pipedream
[5] Schneider Electric Security Bulletin zu Incontroller / Pipedream
[6] CoDeSys-Advisory zu Incontroller / Pipedream
Dieser Beitrag ist auch im monatlichen “Security-Briefing für Hard Hats” erschienen.
