Sonstiges Scada-Sicherheit: Siemens-PLC wird zum Einbruchswerkzeug

Nicht schlecht. Die Jungs scheinen aber sehr IT lastig zu sein bei der wilden Wortwahl.
Meine Steuerungen sind definitiv nicht bei den 28000 mit dabei. Und eine beschriebene Zykluszeiterhöhung auf über 80 ms sollte schnell auffallen. Auf jeden Fall in Produktionsanlagen.

Trotzdem interessant zu sehen was alles so geht.

Bis denn dann

Teddy
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Tja, letztlich sind das doch alles bekannte Themen.
Eine "normale" SPS egal ob Siemens, Codesys oder sonstwas hat nichts OnBoard was als sicher bezeichnet werden könnte.
Sinnvoller weise packt man die SPS in ein eigenes Netz und versieht die entsprechenden Switche mit entsprechenden Accessregeln.
Blöd nur, dass jetzt die ganzen Industrie4.0- und IoT-Dampfplauderer aus ihren Marketing-Löchern kriechen und erzählen, dass der Zugriif per Smartphone auf jede SPS, jeden Sensor und Aktor der letzt Hit ist.
Nur leider hat kaum einer ein vernünftiges Sicherheitskonzept in der Tasche ... Da wird dann was von VPN und VLANs erzählt ohne sich auch nur Gedanken zu machen wie das in ganzen Werk mit hunderten von Maschinen sinnvoll funktionieren soll.

Gruß
Dieter
 
sehe ich das richtig, dass sich der eigentliche Schadcode in FC_1000 und DB_1000 befindet?
Da ist kein Schadcode vorhanden. Außer du bezeichnest SPS-Programmierung generell als Schadcode verbreiten (kommt ja gelegentlich unbeabsichtigt vor).
Es wurde dort nichts anderes gemacht als eine SPS zu programmieren.

Ich habs im Heiseforum schon geschrieben. Das Szenario ist an den Haaren herbeigezogen.

Die T-Bausteine laufen bekanntlich nur auf einer PN-CPU und nur mit deren Schnittstelle.
Wenn ich also Zugriff auf die PN-Schnittstelle bekomme, warum sollte ich dann den Umweg über die SPS gehen? Denn dann bin ich schon in der Schatzkammer und kann schalten und walten wie ich will. Besteht keine Notwendigkeit etwas am SPS-Programm zu ändern.

Das einizge Szenario bei dem das "sinnvoll" sein könnte, ist wenn ich eine PN-CPU mit Ethernet-CP habe, und ich nur Zugriff auf den Ethernet-CP habe. Dann könnte ich mich damit sozusagen ins andere Netzwerk tunneln. Aber wie klein ist die Wahrscheinlichkeit dass man gerade so etwas vorfindet? Also erstmal eine SPS die direkt aus dem Internet erreichbar ist (die Wahrscheinlichkeit ist schon äußerst gering, da sowas schwieriger einzurichten ist als eine VPN-Verbindung), und dann noch in genau dieser Konstellation. Das geht beides gegen Null.

Und was haben die gemacht: Sie haben die T-Bausteine dazu verwendet wozu sie da sind, nämlich Daten übers Netzwerk zu schicken. Und, oh Wunder, das geht. Voll der Hack! Und damit es nicht ganz so peinlich aussieht was man da gemacht hat, nimmt man nicht das passende Werkzeug für sowas (Step7), sondern lädt das mit Snap7 hoch. So kann man wenigstens noch eine github-Seite erstellen, voll 1337.


Und jetzt mal eine Anleitung für einen kleinen SPS-Virus:
Man programmiert mit den T-Bausteinen das S7-Protokoll um Bausteine hoch- und runterzuladen in der SPS. Dann infiziere ich mit diesem Ursprungscode eine Start-SPS, und diese verbreitet einen Schadcode wie auch den Code um sich selber weiterzuberbreiten an alle erreichbaren SPSen. Zyklisch wird geprüft ob der Schadcode in den Partnern noch vorhanden ist, ansonsten wird er erneut nachgeschoben. In einem großen Netzwerk wird das ordentlich aufwändig alle Steuerungen wieder zu säubern.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Und jetzt mal eine Anleitung für einen kleinen SPS-Virus:
Man programmiert mit den T-Bausteinen das S7-Protokoll um Bausteine hoch- und runterzuladen in der SPS. Dann infiziere ich mit diesem Ursprungscode eine Start-SPS, und diese verbreitet einen Schadcode wie auch den Code um sich selber weiterzuberbreiten an alle erreichbaren SPSen. Zyklisch wird geprüft ob der Schadcode in den Partnern noch vorhanden ist, ansonsten wird er erneut nachgeschoben. In einem großen Netzwerk wird das ordentlich aufwändig alle Steuerungen wieder zu säubern.

Der Tipp wurde nun doch umgesetzt:
https://media.ccc.de/v/32c3-7229-plc-blaster :ROFLMAO:
 

Was mich aber doch etwas verärgert ist, dass er seine Erkenntnisse zum Protokoll der 1200 als seine Idee ausgibt. Den Namen "S7comm-Plus" habe ich mir überlegt, und ist meines Wissens nach in keinem Siemens-Dokument wiederzufinden, und ich bezweifle auch dass es die offizielle Bezeichnung von Siemens ist. Das wäre ja absoluter Zufall, dass jemand genau die gleiche Idee für die Namensgebung hat. Das einzige Suchergebnis ist die Sourceforge Seite zum Wireshark plugin.
Meinem Verständnis von Open Source entspricht das zumindest nicht, aber das bestätigt meinen Eindruck den ich mittlerweile vom CCC habe.
 
Was mich aber doch etwas verärgert ist, dass er seine Erkenntnisse zum Protokoll der 1200 als seine Idee ausgibt.

Genau das gleiche habe ich mir auch gedacht, als ich das gesehen habe. Z.B. beim Byte gegen Replay-Attacken: http://www.sps-forum.de/hochsprache...-fuer-s7-protokoll-post506695.html#post506695

Den Namen "S7comm-Plus" habe ich mir überlegt, und ist meines Wissens nach in keinem Siemens-Dokument wiederzufinden, und ich bezweifle auch dass es die offizielle Bezeichnung von Siemens ist.

Also S7comm ist mir bei Siemens auch noch nicht untergekommen. Das "PLUS" schon. So werden z.B. auch Funktionen in den TIA-DLLs benannt, wenn es sich um S7-1200/1500 spezifische Dinge handelt (z.B. Siemens.Simatic.Lang.TisPlusServer.dll)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also S7comm ist mir bei Siemens auch noch nicht untergekommen. Das "PLUS" schon. So werden z.B. auch Funktionen in den TIA-DLLs benannt, wenn es sich um S7-1200/1500 spezifische Dinge handelt (z.B. Siemens.Simatic.Lang.TisPlusServer.dll)

Ja, das "Plus"-Zeug kommt von Siemens, der Bytecode heißt wohl offiziell MC7plus, zumindest hatte das ein ehemaliger Siemens-Mitarbeiter so in seinem Profil stehen.
Diese Datenablage mit variabler Länge haben wir hier im Forum erarbeitet, glaub Jochen hatte da die Lösung. Es kann mir keiner erzählen, dass die beiden Typen das alles nicht gelesen haben wollen. Finds echt schon dreist, und das von einem Typen der Open Source Schulungen macht.

Hast du dir schonmal die Telegramme einer 1200 mit Firmware V4 angeschaut? Laut denen da soll das ja komplett anders sein. Ich könnte mir vorstellen, dass die auch einen Integritätsteil wie bei der 1500 bekommen hat. Bzw. bei der 1500 gab es bei FW 1.5 auch noch eine Änderung im Protokoll, bei dem der Integritätsteil vom Ende an den Anfang gewandert ist.
 
Hast du dir schonmal die Telegramme einer 1200 mit Firmware V4 angeschaut? Laut denen da soll das ja komplett anders sein. Ich könnte mir vorstellen, dass die auch einen Integritätsteil wie bei der 1500 bekommen hat. Bzw. bei der 1500 gab es bei FW 1.5 auch noch eine Änderung im Protokoll, bei dem der Integritätsteil vom Ende an den Anfang gewandert ist.

Nein leider noch nicht. Zum Herumspielen habe ich nur eine V2. Die V4 sind immer gleich beim Kunde verbaut. Soweit mir aber ein Siemens Mitarbeiter bei einer Veranstaltung gesagt hat, möchte Siemens auf den 1200/1500/SP CPUs/Softsps den selben Befehlsatz zur Verfügung stellen. Nur die Leistungsfähigkeit wird beschränkt. Deshalb könnte ich mir Vorstellen, dass das Protokoll auch angepasst wurde. Somit müssen auch nicht X-Varianten gepflegt werden.

Seit kurzem haben wir aber auch eine 1500 im Büro herumhängen und die 1506 Softsps muss ich mal installieren und ein paar Wireshark logs machen. Mir fehlt nur oft die Zeit für das :S
 
Mir kam das auch sehr bekannt vor, ich denke, die haben da einiges von Euch übernommen, was ja nicht verboten ist. Aber eine Erwähnung wäre es Wert gewesen!
Na ja, irgendwie muß er ja auch für sich und seine Firma werben, wenns denn auch mit Know-How ist, das andere mit erarbeitet haben.
Trotzdem fand ich die Vorführung recht gut. Meine Erkenntnis --> zumindest immer Zugangsschutz einschalten, auch wenn es manchmal lästig ist.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@Thomas

Habe noch einmal nachgedacht.
Es wird ja im Vortrag gesagt, dasss das Ganze im Rahmen einer Bachelor-Arbeit gelaufen ist.
Die müßte man doch eigentlich einsehen oder von der Uni/Hochschule anfordern können. Dann wüßtest du es noch ein wenig genauer, auch was die Quellenangaben betrifft.
Und nebenbei gibt es vielleicht noch ein paar neue Erkenntnisse zum Protokoll.
Oder müssen Bachelor-Arbeiten nicht veröffentlicht werden?
 
Oder müssen Bachelor-Arbeiten nicht veröffentlicht werden?

Nein müssen sie nicht, aber wenn sie keinen Sperrvermerk haben, kann man sie beim entsprechenden Prof. einsehen. Ich habe den Talk gesehen und fand ihn bis auf einige Ausreißer ("Niemand möchte mit einem JTAG-Adapter ins Feld laufen, sinnvollerweise schreibt man als erstes einen Bootloader für den Feldbus"..... Was für ein Geschwurbel) ziemlich nett. In der Regel ist das was wir tun, also Maschinen und Prozesse, Roboter und Krempel zu automatisieren, für Standard-Informatiker nicht zu verstehen. Daher cool, dass jemand beim CCC mal wirklich ein bisschen mehr erzählt hat. Die letzten Jahre waren die SPS-Security Talks auf dem CCC meist von Informatikern ohne Automatisierungswissen durchgeführt worden. Da fand ich das hier schon besser.

Ich finde allerdings jetzt, wo ich das hier lese, extrem befremdlich, dass die Vortragenden hier wirklich ohne jeden Hinweis auf Quellen vorgetragen haben, falls wirklich etwas davon von hier stammt.... Danke für die Info.
 
Ich habe dem einen Herren da mal eine Email geschrieben, vielleicht gibt es ja eine Erklärung dafür.
Von einer deutschen Uni habe ich bisher noch keine Rückmeldungen bekommen. Das Protokoll ist in seiner Grundstruktur seit einem Jahr mehr oder weniger vollständig erfasst. Vorher gab es zumindest von eine israelischen Universität auch einen Rückkanal für Informationen.
Bei den Jungs von scadastrangelove darf man auch nicht genau hinschauen. Bei genauem hinsehen haben die das Protokoll überhaupt nicht verstanden, und manche Angriffe funktionieren nur zufällig. Das ist aber wohl das worum es denen geht, irgendwas kaputt machen, einen Vortrag halten und den Fame einsammeln.
Zusammen mit der unterschwelligen Arroganz in den Vorträgen, wie dumm das ganze SPS-System und deren Programmierer sind, geht mir das ziemlich auf den Sack.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Zusammen mit der unterschwelligen Arroganz in den Vorträgen, wie dumm das ganze SPS-System und deren Programmierer sind, geht mir das ziemlich auf den Sack.

Naja.... Wir hinken wirklich in vielen vielen vielen Dingen grauenhaft hinterher, das möchte ich nicht von der Hand weisen. Als Dumm hat mich noch keiner bezeichnet. Aber wenn ich bekannten Informatikern was aus unserer Branche erzähle kann ich schon verstehen, dass das für die einfach so dermaßen abstrus klingt, mit welchen Technologien wir uns rumschlagen.

Der Punkt, wo sie für mich keine adäquaten Diskussionspartner mehr sind, ist erreicht, wenn sie noch nicht mal versuchen, zu verstehen, was bei uns passiert und wieso.
 
Wir hinken wirklich in vielen vielen vielen Dingen grauenhaft hinterher, das möchte ich nicht von der Hand weisen

Ich finde es schlimm das es so viele (nur-)SPS-Programmierer gibt die gar nicht über den Tellerrand schauen wollen - solange verweigern bis man gezwungen ist, (nur)auf bewährtes pochen weil man (wirklich)nichts anderes kann/will,
und kaum andere Erfahrungswerte um wirklich beurteilen/lenken zu können wenn es z.B. in eine neue Richtung geht (mal unabhängig davon ob die Richtung gut oder schlecht ist)

und das ausgeprägte Einzelkämpfertum in der Branche ermöglicht es Siemens überhaupt erst TIA so wie sie es machen auf den Markt zu bringen

und das die Chefs oder Führung immer die bösen sind stimmt so auch nicht immer - wenn sehr viele in der Branche aber "einfach" nur immer meckern und dann eben doch weitermachen, sind dann nach ein paar jahrzehnten die Führungen so wie sie sind

bisher dachte ich immer die Automationsbranche ist knallhart mit ihren Bedingungen bezüglich Qualität(Fehlerhäufigkeit, Funktionalität), Preis und (Echtzeit)Geschwindigkeit -
aber man sieht ja bei TIA und den 1200/1500er sehr deutlich wie wenig formiert die gemeinsame Entwicklerschaft reagiert wenn es nicht gut ist, "Kopf in den Sand - wird schon
werden Mentalität" spürt man da von vielen Seiten

Keine Frage gibt es viele wirklich sehr gute SPS-Entwickler die ein umfassendes und breites Wissen + Erfahrung haben - und Einfluss in der Branche, es sind leider nur so wenige
 
Zuletzt bearbeitet:
Nun ja, wer eine SPS frei ins Internet hängt ist ja schon mit dem Hammer gepudert - aber vielleicht hängt derjenige ja auch sein NAS mit den Naktfotos seiner eigenen Freundin offen ins Internet.:ROFLMAO:
 
Zuviel Werbung?
-> Hier kostenlos registrieren
aber man sieht ja bei TIA und den 1200/1500er sehr deutlich wie wenig formiert die gemeinsame Entwicklerschaft reagiert wenn es nicht gut ist, "Kopf in den Sand - wird schon werden Mentalität" spürt man da von vielen Seiten

Ganz so ist es auch nicht ... Frag mal Siemens wie weit sie in den Verkaufszahlen der 1500er und der ET200SP hinter ihren Zielen hinterherhängen...
 
@LowLevelMan

Wobei man ergänzen muß, dass eine SPS-Programmierer eben nicht immer zwangsläufig aus der Hauptrichtung Informatik kommt, sondern oft eher Maschinenbauer ist. Daher fehlt machmal schon der informationstechnische Hintergrund. Das ist nicht immer nur von Nachteil, denn so mancher vergißt, um was es letztendlich geht, eine Maschine, die irgendwelche Teile produziert und zwar gut, effizient und schnell. Zusätzlich soll sie wartbar und der Code von anderen Kollegen zu verstehen sein. In dem Zusammenhang gehöre ich wahrschenlich eher zu den "Bremsern", die meinen, nicht jede Sau, die durchs Dorf getrieben wird, muß man auch gleich reiten. Siehe Industrie 4.0, das wird spaßig.
 
Zurück
Oben