Jetzt fliegt uns Windows um die Ohren
-
rüdiger schrieb:
Es gibt ja zB diese Geschichte http://en.wikipedia.org/wiki/Siberian_pipeline_sabotage
Das ist eben ein logischer Weg. Man packt in vorhandene Software einen Trojaner rein, verpasst ihm ein Eigenleben, und liefert ihn gleich mit aus.
Das ist eine ganz andere Kategorie, mit ganz anderen Erfolgsaussichten.
-
..
-
Erhard Henkes schrieb:
Anlage inzwischen noch 1:1 so ist wie ausgeliefert UND daß sie am Internet hängt UND daß der Wurm sich auf einem der Anlagenrechner einnisten kann
Das erscheint mir auch sehr unwahrscheinlich. Anlagen hängen normalerweise eher an einem separaten Intranet mit Firewalls gegen außen. Die Chance von innen Schaden anzurichten ist daher am höchsten, also z.B. der oben erwähnte usb-stick mit allem Möglichen drauf.
Geh mal davon aus, dass in den meisten IT-Abteilungen inkompetente Versager sitzen. So könnte man es machen, aber die Realität ist leider traurig.
heise-Kommentar zum Thema:
http://www.heise.de/security/news/foren/S-Re-Kollision-von-Internetzeitalter-und-Jungsteinzeit/forum-186004/msg-19153406/read/noch ein anderer guter Kommentar:
http://www.heise.de/security/news/foren/S-Hat-der-alte-Platon-schon-gesagt/forum-186004/msg-19155389/read/
-
Marc++us schrieb:
rüdiger schrieb:
Wenn man genug Wissen über eine Anlage hat, dann kann man mit dem Wurm sicher schon größeren Schaden anrichten (der kann ja die SPS umprogrammieren und die Änderungen verstecken).
Aber ein SPS-Programm ist etwas anderes als ein Hochsprachenprogramm - es gibt da keine API. Um Schaden anzurichten, muß man die elektrischen Schaltpläne und verfahrenstechnischen Pläne haben, UND den Quellcode des SPS-Programms. Jemand der das hat, ist aber - der Entwickler des Systems.
Das erscheint mir sehr viele "was wäre"-Ketten zu enthalten:
- man entwickelt eine Anlage und nimmt sie in Betrieb
- jemand - ein Geheimdienst - geht hin und entwendet die kompletten vollständigen Planungsunterlagen
- darauf setzt sich jemand hin und entwickelt einen Exploit
- der Exploit ersetzt SPS-Programmteile, passend zu den Planungsunterlagen
- man streut den Exploit aus in der Hoffnung, daß die ursprünglich entwickelten Anlage inzwischen noch 1:1 so ist wie ausgeliefert UND daß sie am Internet hängt UND daß der Wurm sich auf einem der Anlagenrechner einnisten kannDie Komplexität der Operation ist ungeheuer, gleichzeitig ist die Wahrscheinlichkeit auf Erfolg eher gering.
Der Wurm scheint ja sehr flexibel zu sein. Die Erstinfektion erfolgt wohl über einen USB-Stick. Dann scheint es wohl eine Spionage- und Umprogrammierfunktion gegeben zu haben, die man über das Internet Fernsteuern konnte. Aber wie individuell sind denn die ganzen Fertigungsanlagen? Sind das meiste nicht Standardkomponenten?
Gut, die iranischen Atomanlagen dürften schon recht individuell sein. Busher wurde ja erst von Siemens gebaut und dann von der russischen AtomStroyExport fertig gestellt. Aber ein Geheimdienst kommt sicher auch an die Pläne. Irgend einen unzufriedenen Mitarbeiter findet man ja immer.
Wobei dann natürlich die Frage offen bleibt, warum dann mehrere Systeme weltweit infiziert wurden. Ob der Wurm einfach ausgestreut ist, der Inbetriebnahmeleiter den dummerweise auf dem USB-Stick mitgebracht hat oder es sich um einen Versuch handelt das eigentliche Ziel zu verschleiern.
Ich finde die ganze Geschichte auf jeden Fall sehr spannend. Klingt als wäre sie direkt aus einem Spionagethriller.
-
rüdiger schrieb:
Aber wie individuell sind denn die ganzen Fertigungsanlagen? Sind das meiste nicht Standardkomponenten?
Sie sind trotz Standardkomponenten sehr individuell...
Eine Digital-IO-Karte einer SPS kann man immer automatisiert erkennen. Man kann auch das Programm überschreiben, so daß es Ausgang 8.0 auf 24Volt setzt. In Fabrik A hängt an 8.0 das Ventil "Reactor Main Switch" - in Fabrik B hängt an 8.0 die Treppenhausbeleuchtung.
-
Der Wurm sitzt doch nicht auf der SPS, sondern primär auf dem Engineering-PC. Wenn er die SCADA-Software aufgemacht hat, kann sich der Angreifer da drin erstmal gemütlich umschauen und ein paar Vermutungen anstellen, was was ist. Da ist ja Ausgang 0815 nicht nur eine Adresse, sondern ein Objekt mit mindestens Namen und Dokumentationstext.
-
Bashar schrieb:
Da ist ja Ausgang 0815 nicht nur eine Adresse, sondern ein Objekt mit mindestens Namen und Dokumentationstext.
Der Namen hängt doch aber vermutlich an der Schaltplanbezeichnung oder Bezeichnung der zugehörigen Einheit?
Der Versuch ist letztlich gleichbedeutend mit dem Ansatz, einen Parser über den Quellcode eines 3D-Shooters drüberzujagen und aus den Funktionsnamen einen Patch für den God-Mode erstellen zu wollen.
-
Aus der Visualisierung sollte man ja schon einige Informationen bekommt, wo welches Gerät nun hängt. Zumindest schauen die ganzen Beispiele in der WinCC-Broschüre da sehr hinweisend aus http://www.automation.siemens.com/salesmaterial-as/brochure/en/brochure_simatic-wincc_en.pdf
-
Marc++us schrieb:
Bashar schrieb:
Da ist ja Ausgang 0815 nicht nur eine Adresse, sondern ein Objekt mit mindestens Namen und Dokumentationstext.
Der Namen hängt doch aber vermutlich an der Schaltplanbezeichnung oder Bezeichnung der zugehörigen Einheit?
Der Versuch ist letztlich gleichbedeutend mit dem Ansatz, einen Parser über den Quellcode eines 3D-Shooters drüberzujagen und aus den Funktionsnamen einen Patch für den God-Mode erstellen zu wollen.
Unsinn.
Das ist wie, wenn man an die Daten des laufenden Programmes kommt. Und das ist Kinderkacke.
Es gibt Tools, die den Speicher eines Spiels lesen.
Beispiel GTA, das kenn ich von früher:
Man gibt dem Tool den Kontostand des Spiels an. Das Tool sucht den Wert im Speicher. Man ändert den Kontostand leicht durch eine Aktion im Spiel und gibt den neuen Wert ins Tool ein. Nach zwei, drei Werten hat das Tool die Speicherstelle für das Geld gefunden, und man kann den Kontostand auf einen beliebigen Wert verstellen.
-
Aber nur, wenn Du die Visualisierung interpretieren kannst.
Die Visu bei einem an einem SCADA hängenden System ist genau wie der normale Resourceneditor. Da sind einfach Objekte drauf wie "Label1", "Label2", "DigitalIO23", und die Objekte sind dann via Tagbaum (vielleicht direkt) an die IO-Ebene der SPS gebunden.
Wie soll denn die Heuristik des Trojaners auf diese Weise das "Main Reactor Switch Off" finden? Die Bilder sind doch nur einfach Pixel für den Menschen, die haben noch lange keine Logik hinterlegt.
@earli: der Vergleich ist überhaupt nicht stichhaltig. Ein Computerspiel hat nicht so viele Werte, schon bei einer einfachen Maschinen-HMI werden einige 100 bis 1000 Werte eingelesen, und alle haben einen Jitter, d.h. das letzte Bit flattert permanent, so daß kein Wert wirklich so schön konstant ist wie ein Punktestand bei einem Spiel. Es ist auch nicht so, daß man einen Wert einstellt "mach den Ausgang jetzt mal auf 5.3 Volt", und beim Rücklesen des Eingangs kommen dann 5.3 Volt - sondern da kommen 5.2 oder 5.5 Volt. Und das wertet man als "Übereinstimmung". Das ist die Anbindung der analogen Welt, da flattert ständig alles.
Mal eine Frage: glaubt Ihr, daß eine "1" auf einem Mainboard wirklich durch ein 3.3-Volt-Rechtecksignal dargestellt wird?
Ich streite nicht ab, daß der Trojaner Schaden anrichten könnte - ein System würde in einen Notstopp gehen, wenn der da rumwirbelt und Werte manipuliert. Aber mehr? Man würde den Rechner vom Netz trennen, eine Sicherheitskopie einspielen, und geht wieder online.
Das Beispiel mit der Pipeline in Sibirien ist nicht vergleichbar, da hat jemand (Mensch) gezielt Schadcode programmiert, d.h. da wurde gezielt ein Zerstörungsalgorithmus von Anfang an eingebaut.
-
Das ist doch Quatsch, warum sollte man die Visualisierung scannen? Man kann doch die Datenstrukturen im Speicher direkt auslesen.
-
earli schrieb:
Das ist doch Quatsch, warum sollte man die Visualisierung scannen? Man kann doch die Datenstrukturen im Speicher direkt auslesen.
und wie weiß man dann, dass man die richtigen Datenstrukturen ausgelesen hat
-
abc.w schrieb:
earli schrieb:
Das ist doch Quatsch, warum sollte man die Visualisierung scannen? Man kann doch die Datenstrukturen im Speicher direkt auslesen.
und wie weiß man dann, dass man die richtigen Datenstrukturen ausgelesen hat
Das ist doch keine geheime Software. Man weiß, wie das Programm aussieht, das da läuft. Da gibt es irgendwo im Programmcode bzw. auf dem Stack Pointer auf Listen und andere Strukturen, wo die Daten drinstehen.
Mal abgesehen davon geht es ja gar nicht darum, Daten zu manipulieren, sondern Steuerungsskripte. Die sind ja so gemacht, dass man sie verändern kann. Der Wurm macht ja nichts anderes als der Typ machen würde, der das Ding programmiert/bedient.
-
earli schrieb:
Mal abgesehen davon geht es ja gar nicht darum, Daten zu manipulieren, sondern Steuerungsskripte. Die sind ja so gemacht, dass man sie verändern kann. Der Wurm macht ja nichts anderes als der Typ machen würde, der das Ding programmiert/bedient.
und wie weiß der Wurm dann, wie die Anlage im Detail aussieht und welche Zeilen in welchem Steuerungsskript für welches Detail zuständig sind
-
Marc++us schrieb:
Ich streite nicht ab, daß der Trojaner Schaden anrichten könnte - ein System würde in einen Notstopp gehen, wenn der da rumwirbelt und Werte manipuliert. Aber mehr? Man würde den Rechner vom Netz trennen, eine Sicherheitskopie einspielen, und geht wieder online.
"ein" trojaner hat heutzutage fast keine wirkung. wenn man jemandem schaden will gibt es einfachere und bessere möglichkeiten. die ganze botnet entwicklung zeigt doch ganz deutlich in welche richtung die zukunft geht. über diese netze werden dann die attacken gefahren am besten auf die 13 rootserver
-
Marc++us schrieb:
In unseren Kreisen gibt's da gewisse Vorbehalte, weil seltsamerweise die einzigen SPS-Würmer immer ausgerechnet auf den Sicherheitsseminaren gewisser Firmen vorgeführt werden... in der freien Wildbahn hat man keine gefunden. Einige Leute vermuten, daß hier Angebot und Nachfrage in der falschen Reihenfolge auftreten...
Generell halte ich das aber für hanebüchenen Unsinn, daß hier gezielte Attacken ausgeführt werden. Was soll der Wurm denn auf der SPS suchen? Eine SPS ist letztlich Assembler-Code. Da steht nirgendwo eine Funktion "no_switch_on_nuclear_power_plant()". Sondern das sind nur Moves, Or und And, da wird irgendwo ein Ausgang gesetzt, irgendwelche Timer überwachen das, aber bereits bei der gleichen Anlage an einem anderen Standort ist das Programm leicht modifiziert, weil andere elektrotechnische Ausführungsrichtlinien gelten. Auch wird in der Prozessindustrie viel individuell programmiert, erst auf der Baustelle. D.h. das Programm wird vor Ort geschrieben... es gibt da keine generischen Angriffsrichtung.
Natürlich wird man durch so eine Injection ein SPS-Programm zu einer Fehlfunktion bringen können, aber sicherheitskritische Anlagenteile sind regelmäßig zusätzlich noch durch eine in Hardware ausgeführte Failover-Verknüpfung geschützt. Also selbst wenn ein IO nicht mehr richtig gesetzt wird, schaltet sich dann das System ab.
Allgemein findet man in der Industrie fast ausschließlich Windows-Systeme in der SCADA- und Leitebene. Kein Wunder, es gibt ja auch nichts sonst. Die wichtigen IO-Standards (z.B. OPC) wurden von Microsoft und Siemens vorangetrieben, OPC-Implementierungen für Linux sind seltener zu finden, nicht so stabil, und bei SCADAs wird es ganz düster. Alle wichtigen Plattformen und deren Standards sind für Windows: WinCC, PCS 7, iFix, Intouch, usw.
In realen Fabriknetzen geht die größte Gefahr nicht von Trojanern aus (wer das denkt, hat sowas noch nie gemacht), sondern von gottverdammten Inbetriebnehmern, die auf der ganzen Welt mit ihren Notebooks rumreisen, überall ihre USB-Sticks in irgendwelche Ports stecken, eine mp3-, Raubkopie und Pornosammlung mit sich rumschleppen, und dann die Anlagenrechner infizieren. Das ist das größte Problem überhaupt, ich schätze mal, daß man so ein Problem bei 3-5% der Inbetriebnahmen hat.
Ich bin ein großer Anhänger davon, daß man bei Anlagen einfach mit einer Klebepistole die USB-Ports zuspritzt. Das ist die wichtigste IT-Sicherheitsmaßnahme im Fabrikumfeld.
Das würde ich so vorbehaltlos unterschreiben.
BTW: gibt es überhaupt OPC-Server, die nicht im Beta-Stadium sind?
-
Marc++us schrieb:
Ich bin ein großer Anhänger davon, daß man bei Anlagen einfach mit einer Klebepistole die USB-Ports zuspritzt. Das ist die wichtigste IT-Sicherheitsmaßnahme im Fabrikumfeld.
Das ist ja wie das Verbrennen der Schiffe von Hernán Cortés.
Der intelligente User zieht einfach die Kabel innen ab. Viele ECUs haben auch einen HW Switch mit Schlüssel für alle externen unautentifizierten Interfaces. Im Cern kappen die IT Experten die Verbindungen mit der Kneifzange.
Die meisten Fertigungsanlagen sind i.d.T Inselsysteme. R&D Analagen auch.
-
Marc++us schrieb:
Das Beispiel mit der Pipeline in Sibirien ist nicht vergleichbar, da hat jemand (Mensch) gezielt Schadcode programmiert, d.h. da wurde gezielt ein Zerstörungsalgorithmus von Anfang an eingebaut.
Ist doch vergleichbar. Hier hat offenbar jemand geleakten Source in die Finger bekommen und dafür einen Angriff entwickelt. Anscheinend werden ausgewählte Aktionen unterbunden, um einen Fehler auszulösen. Unter Umständen war das Ziel nicht, irgendwas hochgehen zu lassen, sondern nur dauernd einen Fehler auszulösen, so dass die Anlage nicht funktioniert. Und selbst mit Austauschen von (einzelnen) Hardwarekomponenten kann man den Fehler nicht beheben, weil die neuen Teile gleich wieder infiziert werden.
-
Habe deb Thread eben erst gelesen.
Mit WinCC wird die Steuerung nicht direkt programmiert, sondern eher die TouchPanels und andere HMI-Devices. Das Interessante hieran dürften die Strngdaten gekoppelt mit den Verbindungsdaten sein.
Wenn ich ein Eingabefeld mit dem Text 'Selbstzerstörung' finde, wobei die Pinnummer des Merkers in den Verbindungsdaten mitgeliefert wird, müßte ich nur noch einen versteckten Remotezugang mit indirekter Adressierung einrichten und könnte das Ding vermutlich fernsteuern. Also - so ganz ohne ist das nicht.
-
Aktueller FAZ-Artikel zum Thema: http://www.faz.net/s/RubCEB3712D41B64C3094E31BDC1446D18E/DocE8A0D43832567452FBDEE07AF579E893CATplEcommonScontent.html