# Sicherheitslücke in S7



## Ralle (19 Mai 2011)

Das ist schon einmal interessant:http://www.spiegel.de/netzwelt/netzpolitik/0,1518,763529,00.html#ref=rss

Scheint aber eher die populärwissenschaftliche Ausbeute der Erkenntnisse mit Stuxnet zu sein.


----------



## Aventinus (19 Mai 2011)

Da wären jetzt Details interessant.


----------



## hovonlo (19 Mai 2011)

Interessant ist halt, dass sich hier ein amerikanisches Unternehmen ausgerecht auf Siemens-Systeme stürzt. Also ausgerechnet auf die Systeme, die es den Amerikanern erst gestattet haben, sich an den Ultrazentrifugen im Iran auszutoben.

Ich denke jeder, der schon mal mit SPS/Scada/... zu tun hatte weiss, dass es um die netzwerkseitige Sicherheit dieser Systeme nicht zum Besten bestellt steht. Wir haben im Moment was von Rockwell hier bei uns stehen - da sollten auf der Netzwerkseite nicht zu viele ICMP-Pakete an der SPS ankommen, sonst verschluckt sie sich. Bei Siemens reicht ein PC mit Simatic Manager im Netzwerk um an einer Anlage etwas herumzuspielen .... (um nicht zu sagen an die Wand zu fahren)
Prinzipiell müssen Industrienetzwerke sauber vom Rest der Welt getrennt werden *und* die Mitarbeiter müssen sich anständig verhalten - sonst droht Ungemach.


----------



## bike (19 Mai 2011)

Wer an einer Anlage arbeitet mit Step7 und am Netz hängt und dann keine  aktive Firewall hat, dem kann nicht geholfen werden.

Aber es kommt doch gut, zu schreiben Siemens hat Probleme mit der Sicherheit.
Ich kenne andere Hersteller deren Software so sensibel ist, dass wenn eine Taube auf der Netzleitung sitzt das  gesamte System abschmiert.

Also noch habe ich keine Sorgen wegen dieser Lücke 


bike


----------



## SoftMachine (19 Mai 2011)

ihr glaubt doch nicht, dass diese "Lücke" übermorgen noch existent ist ... ?

da werden sich Horden von Entwicklern und Programmieren von S. drauf stürzen und dem ein Garaus machen... !

Gruss


----------



## MSB (19 Mai 2011)

SoftMachine schrieb:


> ihr glaubt doch nicht, dass diese "Lücke" übermorgen noch existent ist ... ?
> 
> da werden sich Horden von Entwicklern und Programmieren von S. drauf stürzen und dem ein Garaus machen... !



Glaubst du noch an das gute im Menschen oder gar den Weihnachtsmann?
Oder fehlen bei dem Post die Ironie-Tags?


----------



## SoftMachine (20 Mai 2011)

Joo, hatte ich vergessen ... ROFLMAOROFLMAOROFLMAOROFLMAO

grützi nach Bayern


----------



## Markus Rupp (20 Mai 2011)

siemens ist doch nur der kapitän des schiffes (ironisch gemeint) codesys-fähige targets sind im mindesten genauso anfällig wie zum beispiel eine saia-steuerung.

bei wago läuft ein linux, welches via c-code auf die eigentlich sps-appi eingreifen kann ohne entdeckt zu werden, auf saia kann ich wenn sie im netzwerk ist via cgi-scripts oder diversen spezielleren telnet-clienten auf die steuerung connecten und den code manipulieren, von beckhoff, berghof und dem rest mal ganz zu schweigen, wie schon mehrmals in diesem thread erwähnt:


Sicherheit beginnt zwar im System, hört aber leider ab (und meißt auch mit) dem programmierer, inbetriebnehmer der sps/scada auf.


----------



## Dos6.22 (20 Mai 2011)

Wenn ich das lese muss ich immer an eine Siemensveranstaltung denken wo Profinet und die Netzwerkfähigkeit der CPUs angepriesen wurde. Das ganze war vor der Iran Geschichte.
Dann kam auch aus dem Publikum die Frage wie geschützt das ganze ist, weil man ja viel Unfug machen könnte.
Laut dem damaligen Siemens Mitarbeiter sähe er da kein Problem. Niemand hätte daran Interesse sich in so ein System einzuhacken.
Und Gegenargumente wollte er auch nicht hören.

Und als ich vor ein paar Monaten bei einer Siemens Schulung war, wusste nicht einmal der Schulungsleiter von dem Hack in den Iran Reaktor.
Da wollte ein anderer Schulugnsteilnehmer wissen, wie das sein kann und was dagegen gemacht wird.
Da mussten wir dem Schulugnsleiter erklären was passiert ist.

Klar kann man es sich einfach machen und sagen, dass System muss abgeschirmt werden. Aber dann beschwert sich am end irgend ein Hansel in der Firma wo die Anlage steht, warum er mit seinem PC nicht direkt auf die Daten von Anlage xyz Zugreifen kann.

Solange die Chinesen nicht im grossen Stil Daten über so eine Lücke ausspionieren oder irgend eine Mafia Vereinigung eine Firma damit erpresst deren Anlage komplett zu zerschiessen, wird da auch nichts gemacht.

Appels OS ist mittlerweile auch anfälliger für Viren, aber es gibt so gut wie keine, daher ist man da relativ sicher.


----------



## MSB (20 Mai 2011)

Dos6.22 schrieb:


> Solange die Chinesen nicht im grossen Stil Daten über so eine Lücke ausspionieren oder irgend eine Mafia Vereinigung eine Firma damit erpresst deren Anlage komplett zu zerschiessen, wird da auch nichts gemacht.



a) Man stelle mal realistisch die Frage wer das überhaupt mitbekommen würde
b) Wenn es wer mitbekommt man das öffentlich erfahren würde
c) Es realistische Möglichkeiten gäbe sowas wirksam zu verhindern, ganz speziell wenn so ein Heiden-Aufwand wie bei Stuxnet betrieben wird.

Sämtliche Experten bestätigen eigentlich im Zusammenhang Sicherheit von Unternehmenskritischen Daten,
das die Schwachstelle seltener die Technik also vielmehr der Mensch ist.


Ethernet als offenes weltumspannendes Netzwerk ist in der Automatisierung ja noch eine relativ junge Modeerscheinung.
Insofern hat es bis vor wenigen Jahren derartige Angriffsmöglichkeiten bei heterogenen Netzen,
ala Profibus und Co. als aufgebohrte serielle Schnittstelle ... ja in keinster Weise gegeben.

Kurzum, schade das nun Siemens als erstes betroffen ist, einen besonderen Vorwurf den man nicht
auch der gesamten versammelten Konkurrenz machen könnte, wäre mir nicht aufgefallen.
Siemens ist was das anbelangt IT-Sicherheitstechnisch genau so finsterstes Mittelalter,
wie jeder andere Steuerungs/Scada Hersteller auch.

Mfg
Manuel


----------



## maxi (20 Mai 2011)

Ich beobachte das angesprochene Thema ja nun schon über 2 Jahre. 
Und smile immer breiter 

PS: Meines wiessenstand ist in den angeblichen Zentrifugen keine WinCC.
Gruß an GE. Mehr sag ich ned.


----------



## LowLevelMahn (20 Mai 2011)

*die Meldung ist auch ganz nett*

http://www.heise.de/newsticker/meldung/Praesentation-neuer-SCADA-Schwachstellen-vertagt-1246212.html


----------



## Tommi (20 Mai 2011)

Mal ne ganz andere Bedrohung:

Bombenalarm bei Phoenix Contact in Blomberg...

http://www.nw-news.de/owl/4506346_Bombendrohung_bei_Phoenix_Contact_in_Blomberg.html


----------



## Thomas_v2.1 (21 Mai 2011)

Mh, ich frage ich da wo die Lücke sein soll. Das ist so als wenn ein Einbrecher durch eine offenstehende Haustür 'einbricht'. Das System ist nunmal offen wie ein Scheunentor.

Was will man denn als Zugriffschutz machen?
Meines Erachtens müsste man den Zugriff auf die Steuerung über gesicherte Zugänge, VPN oder sowas in der Art erledigen. Das sollte mittlerweile auch in einer SPS unterzubringen sein.
Natürlich hilft das nicht dagegen, dass ein infizierter/manipulierter PC welcher autorisierten Zugriff auf die Steuerung hat Schadcode oder manipulierte Daten in die SPS einschleust.

Ausreichend verschlüsselte und autorisierte Verbindungen über andere Bussysteme wie Profibus/MPI sind zwar nicht Standard, wäre aber sicher auch irgendwie möglich. Oder Siemens schmeißt die PG Funktionen auf diesen Schnittstellen generell raus, bzw. man müsste diese irgendwie deaktivieren können.


----------



## Markus Rupp (21 Mai 2011)

wie stellst du dir das denn vor?, verschlüßeltes bussystem, und bei jeder neuen bus-variable oder geänderter teilnehmer-strutkur mußt du das gesamte system neu einspielen (alle teilnehmer-konfigurationen, zertifikate auf allen teilnehmern austauschen).

ein dynamisches zertifikatshandling ist weder einfach noch reel sicher (denn immer wenn ein zertifikat ausgetauscht wird, auch am pc) wird erstmal ne ungeschützte verindung benötigt. also bräuchte ich in diesem fall nur nen deamon der darauf wartet das das zertifikat ausgetauscht wird, das fange ich via kopieren der netzwerkprotokolle auf das deamon-subsystem ab und habe damit das aktuelle zertifikat, schwups kann ich wieder alles manipulieren was ich will.

was die pc geschichte angeht: das problem sitzt nicht IM sondern AM PC. Das ist und war schon immer so.

Zum Thema VPN etc. pp. sind auch nicht die mechanismen zum schutz ein problem, sondern die tatsache das menschen faul sind, und jeder regel folgt eine gegenregel, jedem gesetz ein schlupfloch und jeder sicherheits-geschichte eine backdoor (siehe wincc-stuxnet -> zugriff via master-passwörter, geklaut ja, aber ebend ne existente backdoor)

um sowas in zukunft also tatsächlich zu vermeiden müßte man den menschen das teil des gehirns rausschneiden, was man bauchgefühl nennt -> vulkanier müßte man sein. . .


----------



## Markus Rupp (21 Mai 2011)

hierzu noch ne kurze lektüre:

http://www.heise.de/newsticker/meldung/Praesentation-neuer-SCADA-Schwachstellen-vertagt-1246212.html

das thema wird uns wohl noch länger beschäftigen


----------



## Thomas_v2.1 (21 Mai 2011)

Rupp schrieb:


> wie stellst du dir das denn vor?, verschlüßeltes bussystem, und bei jeder neuen bus-variable oder geänderter teilnehmer-strutkur mußt du das gesamte system neu einspielen (alle teilnehmer-konfigurationen, zertifikate auf allen teilnehmern austauschen).



Sicherheit bedeutet immer auch Mehraufwand, das ist klar. Aber wenn man sich scheut diesen Mehraufwand zu tätigen, braucht man sich auch nicht darüber beschweren wenn alle und jeder die Daten in der Steuerung nach Belieben manipulieren kann.

Leider gibt es ja momentan noch keine Details zu dieser Sicherheitslücke.
Eine Sicherheitslücke in der S7 wäre meiner Meinung nach z.B. die Möglichkeit Sicherheits-SPS zu kompromittieren. Oder in irgendeiner Art und Weise anderen Programmcode in zu SPS einzuschleusen, der vom Programmierer nachher nicht entdeckt werden kann. Quasi wie Stuxnet, aber ohne die Infizierung des PGs.



Rupp schrieb:


> also bräuchte ich in diesem fall nur nen deamon der darauf wartet das das zertifikat ausgetauscht wird, das fange ich via kopieren der netzwerkprotokolle auf das deamon-subsystem ab und habe damit das aktuelle zertifikat, schwups kann ich wieder alles manipulieren was ich will.


Das wäre ja was wenn es so einfach wäre. Oder hast du etwa da das Faktorisierungsproblem für Primzahlen gelöst? Siehe RSA...


----------



## Markus Rupp (22 Mai 2011)

nene hab ich nicht, aber ein jeder sicherheitsschlüßel hat wiederum eine backdoor,worauf ich hinaus will ist folgendes:

entweder vorhandene oder neuere sicherheitsmechanismen nutzen (was die PG Mensch meißt ebend nicht tut) oder aber den stecker ziehen.


und wie ich schon sagte, es liegt weniger an vorhandenen sicherungsmechanismen als an der tatsache das man (Mensch) sie nicht nutzt.


----------



## Deltal (22 Mai 2011)

Ich sehe schon die Renaissance des RUN-P Schalters auf der CPU  

Das mit dem Sicherheitsprogramm könnte wirklich eine schwere Lücke sein. Theoretisch musste ja nur den Sicherheitsbetrieb deaktivieren (geht locker über das PG), danach kann man im F-Programm ja Bausteine ändern wie man lustig ist..


----------



## Tommi (22 Mai 2011)

Deltal schrieb:


> Ich sehe schon die Renaissance des RUN-P Schalters auf der CPU


 

Ich hab' noch einen... 

Gruß
Tommi

PS: den kann man auch stecken lassen...


----------



## Deltal (23 Mai 2011)

Ne.. es geht doch heute nur noch darum wie man die Verantwortung am besten von sich schieben kann.

Also die einfachste Lösung für Siemens ist es den RUN-P Schalter wieder einzuführen, denn dann ist die Verantwortung bei der Person die den Schalter umgelegt hat.


----------



## Ralle (23 Mai 2011)

Deltal schrieb:


> Ne.. es geht doch heute nur noch darum wie man die Verantwortung am besten von sich schieben kann.
> 
> Also die einfachste Lösung für Siemens ist es den RUN-P Schalter wieder einzuführen, denn dann ist die Verantwortung bei der Person die den Schalter umgelegt hat.



Was das Verändern des Step7-Codes angeht ok.

Im Übrigen, Siemens ist nicht allein: http://www.heise.de/security/meldung/SCADA-System-durch-ActiveX-Control-angreifbar-1242762.html


----------



## thomass5 (27 Mai 2011)

ich denke, dies passt hierher...

http://support.automation.siemens.com/WW/view/de/50428932?Datakey=37873821


Thomas


----------



## Thomas_v2.1 (14 Juni 2011)

Ich denke die damals hier im Thread angesprochene Sicherheitslücke wurde jetzt behoben:

http://www.heise.de/security/meldun...cken-in-Automatisierungssystemen-1259623.html

Die geschlossenen Lücken waren aber alle in der S7-1200 mit Firmware-Version 02.00.02.

Bei dem Problem, dass ein abgehörter Datenaustausch erneut abgespielt werden kann und die CPU dieses akzeptiert, verstehe ich jedoch nicht warum das bei der 300/400er Reihe kein Problem darstellen soll. Denn dort ist sowas doch ebenfalls möglich.
Oder der Programmiervorgang bei der 1200er läuft im Vergleich zu den 300/400ern komplett anders ab. So genau habe ich mir das noch nicht angeschaut. Der allgemeine Datenaustausch über das Netzwerk (Speicherbereiche lesen/schreiben) scheint bei beiden Systemen identisch aufgebaut zu sein.


----------



## Thomas_v2.1 (6 August 2011)

Gibt ja mal bei Heise wieder eine Meldung:
http://www.heise.de/security/meldung/Siemens-bezieht-Stellung-zu-den-SCADA-Affen-1318547.html

Interessant ist dabei der Telnet Zugang zu internen SPS Funktionen.

Hier sind die betroffen SPSen und Firmwareversionen aufgelistet:
http://support.automation.siemens.com/WW/view/de/51810333

An alle die auf so eine Version Zugriff haben: per Telnet mit basisk/basisk einloggen und Ergebnisse hier rein


----------



## SoftMachine (6 August 2011)

Hallo

hier
http://support.automation.siemens.c...&viewreg=WW&nodeid0=10805148&objaction=csopen

steht folgendes:
".... Blockieren Sie jeglichen Datenaustausch zu PROFIBUS, MPI und PROFINET Protokoll basierten Geräten außerhalb des Fertigungsbereichs...."

Ist das nicht etwas zu schwarz gemalt 

Wie soll jemand von aussen gezielt Änderungen/Manipulationen im Prog. vornehmen, ohne Kenntnis desselben zu haben ? 

.. Vom STOP oder gar (Ur-)löschen vielleicht mal abgesehen... aber da hat man ja Sicherungen ...

Gruss

P.S.: RUN-P hatte schon was für sich...


----------



## Jochen Kühner (6 August 2011)

SoftMachine schrieb:


> Hallo
> 
> hier
> http://support.automation.siemens.c...&viewreg=WW&nodeid0=10805148&objaction=csopen
> ...



Ich denke den Zugriff sollte man immer Sperren, egal ob es Sicherheitslücken gibt oder nicht, die Variablen lesen bzw schreiben Funktionen sind ja immer offen, und dadurch könnte ja jeder Virus alles mögliche ändern.


----------



## SoftMachine (6 August 2011)

hi Jochen,

sicher hast du recht, bei PC´seh´ich das ebenso...

aber nochmal:
Wie soll jemand von aussen gezielt Änderungen/Manipulationen im Prog. vornehmen, ohne Kenntnis desselben zu haben ?

Gruss


----------



## Thomas_v2.1 (23 Juli 2012)

Was man in den Tiefen des Internets doch alles so findet ;-)

Hier gibts ein Testprogramm welches die hardcodierten Passwörter im Webserver ausnutzen soll:
http://packetstormsecurity.org/files/114745/Siemens-Simatic-S7-300-PLC-Remote-Memory-Viewer.html
Ob man dafür aber ein extra Programm braucht? Die URL in den Browser eintippen sollte reichen.
Jetzt bräuchte man nur noch eine CPU mit dem passenden Firmwarestand...

Die anderen beiden "Exploits" für die S7 mit Run/Stop sind auch Käse, das kann man mit einem Simatic Manager oder libnodave doch schon lange ;-)
Außerdem funktioniert das Programm mit den hardcodierten TSAPs für eine S7-400 auch nur wenn die CPU auf dem richtigen Steckplatz sitzt.


----------

