 Eine der offensichtlichen kritischen Infrastrukturen, die wir haben, ist Stromerzeugung. Wenn wir keinen Strom haben und keine Energie haben, dann sind wir ziemlich am Hintern. Unser nächster Sprecher schaut jetzt aus sich die Kontrollsysteme dieser Power, dieser Stromturbinen genauer an und deren Probleme. Das heißt bitte, heiß Reptap, Moderek und Kurs, ganz herzlich willkommen. Guten Morgen, Kongress. Danke, dass ihr so früh aufwacht am Morgen für uns. Wir sprechen heute über die Sicherheit von Stromkraftwerken, und zwar genau gesagt über Automatisierungssystem in diesen Stromkraftwerken. Und dann könnt ihr ja denken, ah, das ist ein weiterer Talk über wie unsicher diese ganzen Industrie-Standards sind und so weiter. Und ja, das ist es eigentlich auch. Und jahrelang haben wir mit meinen Kollegen über diese industrielle Sicherheit in der Industrie gesprochen. Und wir sehen das Sachen besser werden, aber das Tempo ist etwas anders als in der privaten Wirtschaft. Und wir werden heute darüber sprechen, wie diese Stromkraftwerke gebaut werden, was ihre Eigenschaften sind und so weiter. Und zuerst, wir sollen das mal vorstellen, wir sind eine Sicherheitskonzultenfirma, und wir haben viele industrielle Dinge, die SCADES, DCS und so weiter kontrolliert. Wir haben das also sehr lange gemacht, und wir haben es so lange gemacht, dass wir eine riesige Karte an Kontakten haben. Und wir machen das nicht nur für Stromkraftwerke und so weiter, sondern wir sprechen auch mit anderen Einheiten und versuchen Sicherheitslücken zu schließen. Wir arbeiten mit Kaspersky und betreiben dort Forschung, und zwar nicht nur von mir, sondern auch von Evgenia und Zergame. Was man definitiv feststellen ist, ist, dass alles, was wir hier diskutieren, ist, dass es die entsprechenden Hersteller darüber bereits informiert worden sind, und zwar vor langer Zeit. Man sieht, dass die Hersteller, aber man sieht verschiedene Hersteller, aber eigentlich sprechen wir hier bei einem Hersteller, nämlich Siemens. Und wir wollen aber, dass ihr versteht, dass es ähnliche Sicherheitslücken auch bei anderen Herstellern von industriellen Lösungen gibt. Einige der Findings brauchen jetzt nicht gerade Wochen von Arbeit, um sie herauszufinden, und das gilt auch für alle anderen Hersteller, die hier nicht bemerkt werden. Wenn wir jetzt mal die Witze beiseite schieben, dann zeigen wir die Sicherheitslücken von echten Kraftwerken, die da draußen sind. Und das könnte jetzt aussehen, als wäre das sehr unverantwortlich, aber tatsächlich ist es genau andersrum. Um diese Art von Forschung zu betreiben mit diesen Systemen und diesen Kraftwerken, muss man zugehört diese Kraftwerke haben. Man muss auch Zeit, diese Forschung zu betreiben, man muss das Wissen haben, um diese Forschung zu betreiben. Und all diese Ressourcen sind sehr begrenzt für Leute wie uns und für die Betreiber dieser Kraftwerke. Aber für die Bösen, also die möglichen Anangreifer, das ist ja deren Job. Das heißt, die haben sehr viel Anreiz zu forschen, und deswegen glauben wir, dass die Bösen das eigentlich schon wissen. Und wir wollen diese Informationen weiter verbreiten, so dass sie auch die guten das Wissen und dagegen ankämpfen können. Okay, schauen wir uns mal den Talk selbst an. Kraftwerke. Kraftwerke ist die normale Art und Weise, wie Menschen ihre Elektrizität bekommen. Also, sie sind überall um uns, denn die nächste an Leipzig ist soweit ich weiß, das Lippendorfer Kraftwerk. Und wenn, als wir dann das geforscht hatten für diese Einführung, haben wir festgestellt, dass es ganz schön viele Infos über diese Kraftwerke gibt. Zum Beispiel auf Google Maps gibt es ein Bild, aber das ist noch nicht alles. Sondern du siehst auch auf den Marketingmaterien von den Herstellern, siehst du auch Schematar. Und wenn die Hersteller diese Kraftwerke verkaufen, dann starten sie natürlich mit dem Bauen der Gebäude. Und auf den Webseiten von diesen Herstellern findet man teilweise dann genaue Lagepläne, wo welche Ausrüstung gelagert wird und wo welche Tools sind. Aber wenn man diese Zugriff in nicht hat, dann kann man das einfach googeln und dann weiß man, welche Systeme für Automatisierung benutzt werden. Also in Lippendorf zum Beispiel ist es ein Siemens SPPA T2000 und SPPA P3000. Und die haben ein anderes Siemens System innen drin, das ist SPA T15, glaube ich. Und das ist ziemlich verwirrend und wir sind auch verwirrt. Aber das ist genau das System, auf das wir uns konzentrieren werden heute, das Siemens SPPA T2000. Und es könnte auch jedes andere Automatisierungssystem sein, aber wir haben nur zufällig dieses System öfter gesehen als andere. Man kann auf der ganzen Welt auf dieser Karte sehen, welche Kraftwerke auf der Welt existieren, dank der Carbon überwachungsfirmen und Communities. Also das ist nicht nur Kraftwerke, sondern auch Wind und Wellenkraftwerke und so weiter, die sind mit verschiedenen Farben hier markiert. Zum Beispiel gibt es hier Kohle und Gas. Das Thema ist richtig riesig. Aber worauf wir uns heute konzentrieren werden in diesem Talk ist vor allem die Kraftwerke, die mit Kohle und Gas arbeiten. Das ist wichtig zu sagen. Das Herz hier des Kraftwerks ist eine Turbine. Wir haben kein Bild einer Turbine hier auf der Folie, aber du hast es schon mal auf einem Flugzeug gesehen und ähnlich sieht das aus auch von der Größe und wie sie funktionieren in Kraftwerken. Auf den Webseiten der verschiedenen Herstellern kann man viele Informationen über diese Turbinen finden und wo sie eingesetzt werden. Zum Beispiel ist das die Karte der Turbinen von Siemens. Nicht alle Turbinen werden in Kraftwerken benutzt. Es gibt auch verschiedene andere Einsatzbereiche, zum Beispiel chemische oder Gasverarbeitung. Aber wenn man diese Informationen mit den Informationen von der vorigen Folie verbindet, dann weiß man ziemlich genau, welches Kraftwerk, welches Turbine benutzt wird. Und man kann dann sogar herausfinden, welche Versionen von diesen Systemen hier benutzt werden. Das ist wichtig, weil wegen der Verwundbarkeiten, die wir heute besprechen werden. Bevor wir also jetzt anfangen, darüber zu sprechen, was ist die Automatisierung, sollten wir darüber sprechen, wie funktioniert ein Kraftwerk. Also wir werden natürlich einige Sachen sehr vereinfachen, um das für die Zuschauerschaft besser verarbeitbar zu machen. Und auch, weil wir selber nicht alles perfekt verstehen. Aber das Erste, was man braucht, ist Treibstoff, also Öl oder Kohle oder Gas. Und diesen Treibstoff, den tust du in der Verbrennungskammer, wo der Treibstoff verbrannt wird. Und das generiert viel Druck. Und der Druck geht in die Turbine und durch den Druck rotiert die Turbine und die hat einen Schaft, der einen Elektrizitätsgenerator antreibt, der Elektrizität generiert offensichtlicherweise und den in das Stromnetz einspeist. Und von jetzt müssen wir verstehen, dass wenn wir Elektrizität generieren, dann generieren wir nicht nur den Strom für dieses Kongresszentrum oder dieses Stadt, sondern wir tun das in die Stromnetzeinspeisen, wo andere Leute dann dieses verkaufen. Es gibt auch eine sehr interessante Sache. Wenn wir der Verbrennungskammer, dann ist natürlich ganz viel Hitze da und wir müssen damit klarkommen. Eine Möglichkeit ist es, das sicher in die Luft zu blasen über Kondensstürme oder eine andere Option ist, wir können die Hitze nehmen und Wasser zum Beispiel erwärmen, das Wasser zu Wasserdampf und der Wasserdampf treibt eine Dampfturbine an, um weiter Strom zu erzeugen. Das ist natürlich eine Optimierung in gewisser Weise. Was ist jetzt hier die Automatisierung in diesem Prozess? Die Automationssysteme in Kraftwerken sind in der Regel verteilte Kontrollsysteme oder DCSs. Alles, was ich gerade gesagt habe oder beschrieben habe, ist irgendwie automatisiert mit dieser Systeme. Die Hersteller solcher Lösungen wollen das natürlich vereinfachen für die Betreiber, weil sie nicht 100 Leute in einem Kraftwerk arbeiten lassen wollen, sondern vielleicht nur einen Dutzend, und die wollen den ganzen Prozess vereinfachen. Ines egal, wo das Gas oder die Kohle herkommt oder wie viel sie davon brauchen, sie sollten einfach nur den Prozess stoppen und starten können und sie sollen eine Sache kontrollieren können, nämlich wie viel Energie ins Energie-Netz eingespeist werden sollen, wie viele Megawatt wir einspeisen wollen und produzieren wollen. Das beschreibt die Komplexität, die hinter diesen Lösungen versteckt wird. Das sind natürlich viele kleine Dinge, die wir noch ein bisschen später diskutieren werden, die da drin passieren. DCSs werden nicht nur bei Kraftwerken benutzt, sie werden auch in anderen Horten verwendet. Die selbe Lösungen, die selbe Software und Software. DCSs ist nicht nur eine Software, die du installierst. Es ist ein Satz von Hardware und Software, Input-Output-Modelle, Sensoren und so weiter. Die haben quasi einen eigenen Bereich für Kraftwerke. Das ist so eine komplexe Sache. Es gibt viele Hersteller, die sich damit beschäftigen, wie ich gesagt habe. Wir werden in diesem Vortrag hauptsächlich auf das Siemens eingehen. Eine kleine Beschreibung, wie wir die Sachen vereinfachen für die Betreiber dieser DCS-Software, wenn wir zum Beispiel die Frage beantworten wollen, wie würden wir regulieren, was wir an Megawatt ausbuchen in unserer Kraftwerk? Wir müssen eigentlich drei Sachen kontrollieren. Wir machen natürlich hier vieles zu einfach. Man würde also für den Beispiel einer Gas-Turbine, wir würden regulieren, wie viel Gas wir in die Verbrennungskammer einspeisen. Wir würden die Flammentemperatur kontrollieren wollen und wir wollen das kontrollieren, was Luft in die Turbine bringt. Das sind im Wesentlichen drei Sachen, die wir mit unserem System kontrollieren wollen und 100 Megawatt auf 150 Megawatt ändern wollen. Das System selbst, das wir angucken werden, das heißt Siemens SPPA T3000 und nochmal alle anderen DCS-Systeme von anderen Herstellern sind ähnlich. Das ist ein typisches industrielles System. Es hat all die ganzen typischen Sachen, OPC, Verkehr, Server, die Militarisierung. Das Einzige, was anders ist für das Siemens SPPA T3000, die haben zwei Hauptkomponenten, den Application Server und den Automation Server. Die Software, die auf diesen Servern läuft, ist nicht, was du in anderen Installationen finden wirst. Abgesehen von diesem Fakt, wenn du die Handbücher von Siemens Systemen liest, dann wirst du verschiedene Netzwerke und Strukturen beschrieben sehen, dass es zum Beispiel keine Verbindungen gibt zwischen dem Applikation-Netzwerk und dem externen Netzwerk. In der Realität wirst du natürlich Sensor-Netzwerke finden, die zum Beispiel Vibrationen von Objekten, Monitoren oder Geräusche in der Turbine. Alles in allem. Die Betreiber solcher Kraftwerke haben nicht Ingenieure, die an der Seite stehen und das warten, sondern das wollen sie von Remote machen. Sie wollen Updates machen. Sie würden OPC-Verkehr darauf schieben wollen, zum Beispiel auch zu ihrem eigenen Firmennetzwerk oder natürlich zu Regulatoren, weil der ganze Markt gemunitert wird, wie viel Energie du produzierst und wie viel du produzieren sollst, wird von Regulatoren beobachtet, damit du deinen Strom verkaufen kannst auf dem Energiemarkt. Das wird unser Struktur sein. Wir werden erst mal über Automation-Service-Netzen, erst über die Anwendungsserver und dann über Automation-Service sprechen. Okay, fangen wir an mit dem Prozess mit einem kontrollierten Verwundbarkeitsveröffentlichungsprozess. Wir haben ungefähr von einem Jahr die Hersteller kontaktiert. Am Anfang Dezember hat Siemens ein Ratschlag veröffentlicht. Es waren nicht nur die Sachen von uns drin, da waren auch noch andere Leute, die dazu beigetragen haben. Dieses Jahr in Dezember bedeutet nicht, dass Siemens das jetzt direkt veröffentlicht hat. Dieses System wird exklusiv unterstützt. Wir haben Siemens über ein paar Sicherheitsverwundbarkeiten informiert und sie haben ein Budget gemacht, sie haben geschaut, welche kritische Infrastruktur sie damit betreiben und haben hoffentlich einige Sachen gefixt. Es gibt viele Sachen, die wir hier überspringen müssen, weil wir ein bisschen Zeitnot sind. Nicht alle Verwundbarkeiten sind die gleichen und wir benutzen jetzt hier CVSS, um darüber zu sprechen, wie kritisch solche Verwundbarkeiten sind. Aber das ist vielleicht nicht unbedingt vernünftig, wenn man so ein Industrie-Netzwerk hat. Man kann hier ein paar Sachen sehen. Wir überspringen das. Es gibt einen Ankunftsmodell in einem White Paper, das wir später im Januar irgendwie hoffentlich veröffentlichen werden. Okay, der Anwendungs-Server. Das ist die Hauptressource, die wir in dem SPPA und T3000-Netzwerk finden. Wenn sich jemand remote über das System verbindet, dann endet man am Application-Server. Wenn ich jetzt einige Werte ändern würde oder so würde ich mit diesem Application-Server sprechen, wenn es andere Server gibt, die sich mit dem Application-Server verbinden werden, dann fangen die damit an, dass die ihre Software vom Application-Server herunterladen und dann ausführen. Das heißt, das Erste, was wir feststellen ist, dass sehr viele Netzwerk-Ports offen sind auf dieser Maschine und das ist der erste Punkt. Das ist ein riesiges Angriff, eine riesige Angriffsfläche. Das heißt, wenn wir einige Sim-Software und andere Software komprimitieren wollten oder so, dann haben wir hier richtig viel Angriffsfläche und das fängt auch damit schon an, dass alle diese Installationen von diesem SPPA-System unterschiedlich sind. Das heißt, es kommt auf die Version und die Generation an. Das heißt, man findet verschiedene Windows-Versionen von 2003 bis 2016 und hoffentlich werden die alle jetzt gerade abgedatet, denn der Update-Prozess für diese Installationen ist sehr schwierig. Also man sollte dann darauf warten, bis sowieso ein Wartungsvorgang ist und das heißt, man sollte das alle halbe Jahr oder alle Jahr machen, aber man findet immer so ein Fenster, wo man so einen Exploit ausnutzen kann und diese Vulnerabilities immer noch offen sind. Es läuft tonnenweise zusätzliches Software da drauf, z.B. altes Siegwin, schlecht konfiguriertes Tomcat und wir haben hier diese lustigen Wartendiagramme, die zeigen, wie die verschiedene Konfigurationen liest, die mit der Software mit den schlechten CIS-Werten ist und das sind Werte, die zeigen, wie schwierig oder wie angreifbar es ist. Dann haben wir da viel Java-Software und Radut wird euch darüber dann was erzählen nachher. Und große Überraschung, eines der größten Probleme oder eines der offensichtlichsten Probleme mit dem Siemens SPPA 3000 ist tatsächlich Passwörter. Es hat drei wichtige Passwörter. Das erste was ist auf den Installationen vor 2014 oder 2015. Alte Passwörter für diese Kraftwerke, alle Passwörter für diese Kraftwerke waren dieselben und die volle Wörterliste wurde schon in verschiedenen White Papers publiziert und nach einer Weile hat Siemens einzigartige Passwörter für diese Kraftwerke generiert. Aber bis dieses Jahr war es sehr schwer, dieses Passwort zu ändern. Das heißt, man musste den Prozess wissen, man musste den Systemintegrator kontaktieren und ab diesem Dezember ist es deutlich einfacher, diese Passwörter zu ändern. Das heißt, früher war es so, dass man, selbst wenn man über diese Probleme Bescheid wusste, dann konnte man trotzdem nicht oft nicht einfach das Passwort ändern. Mit den Passwörtern kann man auch die ganzen Diagramme und die Integrator-Dokumentation finden, die einem zeigt, wie dieses System aufgebaut ist, wie es arbeitet und so weiter. Das wurde nicht von Siemens publiziert, sondern von einigen Kraftwerksbetreibern, die dachten, das ist eine gute Idee, diese Informationen zu verbreiten. Also wie gesagt, die wichtigste Sache, diese Application Server ist ein Haufen Java Software und bitte begrüßt jetzt Rado, der euch da mehr darüber erzählen wird. Hallo zusammen! Jetzt schauen wir uns mal die Software an, die auf dem Application Server läuft. Das erste ist irgendwie einen Thin Client, der über HTTPS mit Browser kommuniziert und mit dem Server. Das heißt, der kann außerhalb das Application Network sein und da kann dann eine Firewall dazwischen sein. Es gibt auch die Technik des FAT Client, der dann direkt mit der RMI Registry kommuniziert, um Services zu finden und dann mit diesen Services zu sprechen direkt. Und deswegen sollte ein FAT Client in das Application Network gehören. Der Aufbau, die Architektur dieses Systems wurde von SPPA zur Verfügung gestellt und hier haben wir die Items, die... Hier kommen Sachen vom Thin Client und die werden dann weitergeladet an die RMI Services. SPPA kommt bezüglich besteht aus Containern und die haben jeweils mit einem oder mehr RMI Services. Alle Arten von diesen Containern sind hier auf dieser Instruktion gezeigt und alle haben selbsterklärende Namen. Also, bevor wir da weiter tiefer eintauchen, zeigen wir euch erst einige Werkzeuge. Das erste davon ist, alle Java-Files sind natürlich obviscated, aber diese Sicherheitsmaßnahmen können einfach umgangen werden mit öffentlich verfügbaren Werkzeugen. ELSA zum Beispiel. Also, manchmal ist es wichtig zu sehen, wie die Software miteinander kommuniziert und es hilft, die Architektur zu verstehen und auch die Workflows mit den Clients. Und bei SPPA wurde ein Software damit das RMI-Disektor geschrieben. Und das macht diese Calls in menschenlesbare Format, wandelt die um. Und wenn wir jetzt hier Read-Orgy von dem Java-Stich herausfinden, das ist unsicher. Ja, habe ich jetzt gar nicht verstanden, sorry. Ein Problem von SPPA ist, da haben wir da eine Config-File und die kann über dieses Software von dieser Ordner enthält einige Informationen über das System, zum Beispiel Konfigurations-Dateien, Start-Optionen, Konfigurationen von allen Containern als Anwendungsarbeit oder ein Anwendungs-Netzwerk. Das gibt natürlich auch ein paar Informationen aus dem Tomcat, die wir darüber erreichen können. Okay, über Tomcat. Es gibt drei Web-Anwendungen. Man kann von der Remote-Diagnose machen, ein Manager machen, und das dritte habe ich leider nicht verstanden. Man kann über HTTPS-Zucker erreichen auf einige Komponenten. In XML-Dateien gibt es eine Liste aller Anwendungen und die Liste ist sehr, sehr lang. Einige dieser Netze haben attraktive Namen für Angreifer, zum Beispiel Browser-Net, Browser-Servolet. Es lässt die Verzeichnisse auf vom Betriebssystem, aber es gibt noch andere Sachen, die sind vielleicht noch mehr interessant sind, zum Beispiel File-Upload-Servolet, um Dateien hochzuladen. Man darf unautorisiert Dateien hochladen, die dann Systemrechte erhalten. Man hat komplette Kontrolle über den Namen der Datei. Das kann natürlich extrem leicht in Remote-Code-Execution umgewandelt werden. Man kann einfach Skriptisch-Daten in die Tomcat-Web-Applikation einschleusen. Und dann hast du Remote-Code-Execution mit Systemrechten. Es gibt außerdem einige Services-Servolets, die Service-Factory im Namen stehen haben. Das leidet HTTPS-Anfragen um auf Services in diesen Service-Factories. Man kann also zum Beispiel bestimmte Sachen suchen, die man interessant findet und später noch einen weiteren Code ausführen zu lassen. Und die Methoden kann man in Serialen Objekten definieren im Datenbereich. Und natürlich gibt es auch Parameter dafür, die man hier in diesem Objekt definieren kann. Jetzt haben wir hier eine Situation, wo Schlanker und Fetter-Client über Remote-Services erreichen können. Aber der Fett-Client kann sogar direkt mit der Registry kommunizieren. Wenn also ein Anwendungsserver wichtige Yamaha-Script-Updates verpasst hat, dann hat das vermutlich sehr große Verwundbarkeiten. Und wir können dann einfach diese Sachen, diese Schwachstellen ausnutzen und Code-Execution mit Systemrechten erlangen wieder. Die nächste Aufgabe wird sein, alle RMA-Services auf Listen zu lassen. Als ersten Schritt werden wir einfach die Registry an und bekommen eine große Liste von Services, von Diensten. Fast alle sind eine bestimmte Art. Ungefähr alle haben eine allgemeine Kontrollschnittstelle. Um weiter da genauer hinzuschauen, haben wir uns mal ein Look-up-Service angeschaut. Dieser Service sieht sehr aus wie eine Sammlung von anderen RMA-Services. Wir können die öffentliche Methode List benutzen, um alle verfügbaren Services aufzulisten. Und den Namen und Public Method Look-up können wir die Attribute bekommen. RMA-Services in diesem Schritt haben alle das Service Factory als Schnittstelle implementiert. Wir können also davon ausgehen, dass diese Sammlung, eine weitere Sammlung von RMA-Services ist, aber es hat keine öffentliche Schnittstelle, um den Namen des Services zu bekommen. Wir werden also ein bisschen die Klasse D kombinieren und ein paar Factory-Methoden finden, die RMA-Services erstellen. Zum Beispiel über Skripte. Darin können wir dann vielleicht Crate-Services finden. Mit der öffentlichen Methode Get-Service in String als Name können wir dann die Referenz bekommen für den nächsten RMA-Service. Und im letzten Schritt kriegen wir die Referenz zu RMA-Services, die echte Jobs ausführen. Aber diese RMA-Service hat natürlich wieder viele öffentliche Methoden für autoresierte Benutzer. Um es zusammenzufassen, in der Registry können wir über jedes Level viele RMA-Services finden und die letzte enthält auch viele öffentliche Funktionen. Also die Angriffsoberfläche ist wirklich verdammt groß in diesem System. Wenn wir jetzt alle RMA-Services auflasten, die verfügbar sind, dann sind die nächsten Fragen. Gibt es da irgendwie Authentikation, Authentifizierung für Client Request um zu sehen, wie Client Anfragen an Service Factories processiert werden? Und zwar mit einer Client ID, mit einer kleinen Identifizierung. Wir benutzen diese PC Service Factory, die versucht, eine valide Session zu erstellen mit dieser Client ID im Session Manager. Wenn der Session Manager seine Aufgabe nicht schafft, dann wird eine Exception geworfen. Und wenn es aber weitergeht, dann kommt eine valide Session ID zurück an die PC Service Factory und die wird dann eine Instanz von Security Service mit einer Factory Methode. Und der Wett der Session ID wird in einer Variable in einem Login ID gespeichert innerhalb der Security Service. Und am Schluss bekommt der Client die Referenz zu Security Services. Das heißt, ob da keiner dann einige öffentliche Methoden davon aufrufen, aber diese Methoden können die vorherigen Checks mit der User Checks nochmal durchführen mit diesen IDs im Security Manager. Das heißt, wir haben zwei Sicherheitsmaßnahmen in diesem System, aber die Frage ist, wie kann ein Angreifer eine Operation durchführen, wenn er keine Client ID hat. Und in diesem Fall ist es so, dass der Session Manager wenn das wir den Session Manager das bringen, ID geben und der Client ID wird dann dorthin benutzt. Und damit können wir dieses erste Schloss einfach umgehen. Das heißt, eigentlich haben wir nur eine Sicherheitsmaßnahme auf diesem System. Und die ist ganz an eine eine Methode von einem Service weiter überlassen. Aber wir wissen ja, diese Anzahl an RMI Services ist riesengroß und die Anzahl der öffentlichen Methode noch viel größer. Das heißt, es ist echt schwer geworden, die Sicherheitssysteme des Systems über den Überblick zu behalten, zumindest laut dieser Information. Also wir wissen jetzt, wir müssen alle Eingaben dieses Systems und wir wissen alle Sicherheitsmaßnahmen des Systems. Das heißt, jetzt ist es Zeit bei Wundbarkeiten zu finden. In der Liste der RMI Services findet der sieht ziemlich interessant aus. Admin Service den kann man als Anonyme Session benutzen mit diesem vorigen Script. Und er hat eine öffentliche Methode an Script und die checkt überhaupt nicht das Script ab. Das heißt, wir können die einfach ausführen, ohne vorher irgendwie uns einzuloggen. Und das erste Schritt ist, im ersten Schritt stellt der eine Instanz von und es ist so, dass dieser Schritt einfach irgendwelche arbitrierenden Java-Klassen lädt. Und diese Klasse sollte das Admin Script ausführen und dann alle IP-Adressen finden. Und das wird dann von RunScript ausgeführt in RMI Services. Dafür stellen wir eine Java-Klasse, die einfach nur das Code ausführt. Mit die Argumente, die wir geben als Code. Und das wird mit Systemrechten ausgeführt. Natürlich gibt es noch weitere können wir noch viel mehr machen, nachdem wir dann die Exploration fertig haben, als nur irgendwelchen Code ausführen. Damit können wir auch arbitrierere Java-Klassen innerhalb laufender SPPA-Anwendungen einschleusen. Wir Java Reflection benutzen, um Variablen zu patchen das Systems und damit die Technologieeigenschaften zu beeinflussen von SPPA. Weiterhin ist es so, dass die vorigen Checks umgehen, werden können mit einer anderen Verrundbarkeit in Session Services. Das Service hat eine Methode namens GetLoginSessions und diese Methode gibt alle Session-Data zurück von allen eingelockten Usern. Diese Information beinhaltet Usernames, IP-Adressen und ClientID. Das heißt, wenn diese ClientID von einem User der Admin-Privilegien hat, kann ein Angreifer diese ClientID benutzen, um eine Referenz auf Security Service zu benutzen und diese Referenz wird mit einer privilegierten Session geliefert. Weiterhin können die Angreifer dann öffentliche Methoden von Security Service an aufrufen und nämlich GetAllUsers und kriegen denn alle Privatinformationen über alle User des Systems und Passwort Hashes sind da auch mit in diesen Privatinformationen enthalten. Also nur um zusammenzufassen, wir haben beide Verrundbarkeiten, die uns erlauben über HTTPS Daten abzugreifen und durch die Firewall und beide Sicherheitsmaßnahmen können umgehen werden. Alle Kommunikation mit den RMI Services ist verschlüsselt generell. Also Benutzernamen und Passwort Hashes werden also nicht verschlüsselt, d.h. die Passwort Hashes werden in Klartext übertragen und die Benutzernamen das ist sehr kritisch für den FatClient Case also die FatClient Fall der dicke Client und jetzt Passwort Hashes heißt es gibt auch keine Session-Schutzmechanismen d.h. wenn ein Angreifer einen mannenden Mittelangriff gegen einen Benutzer ausführen muss und damit Traffic abrufen kann dann zwischen dem von dem UserApplication Server dann keine einen validen Benutzernamen und Passwort Hashes von diesem System aufbauen und das einfach weiter benutzen und damit Operationen auf dem System durchzuführen und was er auch machen kann ist er kann das Passwort von diesem Benutzern ändern ich spreche viel über Benutzernamen und Passwort Hashes d.h. es ist jetzt mal Zeit dass wir herausfinden wie das System diese beiden organisiert Hi, ich würde dann mit der Diskussion über den Anwendungs-Server weitermachen man kann hier auf der Feuer sehen oder man konnte vorsehen wie Remote Execution ausführungen von Code erreicht haben und jetzt rede ich darüber wie wir das lokal machen können nachdem das System gestartet ist wurde fängt es an 2 Dateien zu lesen diese 1.xml und pdata1.exm und checkt dann die Passwort-Situation in der User1-Datei eine einfache xml-Datei die pdata der Tei hat eine komplizierliche Struktur okay jetzt gibt es dann also diese spezielle xml-Datei die Felder der xml-Datei sind auf das Leit die ihr sehen könnt die werden benutzt um Haswert zu berechnen und das Passwort zu überprüfen während der Anwendung außer auf der unteren Seite im Sodecode es ist ein typisches Schema Unit Machine es hat eine Nummer von Durchläufen Quellen und Senken sind hinzugefügt worden es ist aber dasselbe für alle Benutzer okay das Tool für Passworte herauszubekommen ist aus dem pdata 1-File wurde entwickelt und auf der Folie kannst du sehen was herauskommt das Tool kann benutzen werden um die Passwort da zu überprüfen zum Beispiel mit Dictionary ankämpfen und das Tool könnt ihr auf dem Link dort unten finden okay unter dem Strich haben wir den Applikationsserver analysiert wir haben gesehen dass es einen riesengroßen Angriffsoberflächen gibt und das unter anderem dabei sind ganz viele verschiedene Komponenten gemeint sind dann haben wir herausgefunden dass man von der Erferne Zugriff erreichen kann ob oder ob nicht SPP Remote Connection angeboten hat das ist gar nicht so wichtig weil jemand anders kann Konfiguration falsch gemacht haben du solltest es auf jeden Fall darüber nachdenken und das letzte was wir gemacht haben einen Ankäufer hat auch die Möglichkeit den Stromerzeugungsprozess zu beeinflussen zum Beispiel ein Start und Stop oder den Ausput was mit Produktion zu verändern und natürlich kann man Informationen abgreifen vom Anwendungsserver aus okay das war es mit dem Anwendungsserver jetzt haben wir den Automationsserver darüber wollen wir jetzt sprechen der Hauptziel des Automationsservers ist natürlich in Echtzeit Automationsfunktionen und Aufgaben auszuführen abhängig von der Projektarchitektur des Kraftwerkes und deren Eigenschaften das kann natürlich ein bisschen unterschiedlich sein aber wir haben drei verschiedene Rollen entdeckt da gibt es einen kleinen Konflikt weil dieser Begriff auch schon für den Server benutzt wurde aber bei der Automationsserver Konfiguration und bei öffentlichen Informationen die wir finden konnten haben wir gefunden dass diese Rolle quasi dieselbe Hardware und Software benutzt und wir haben gesagt wir werden einfach diesen Begriff verwenden das wird vielleicht weniger uns verwirren zur selben Zeit es ist natürlich ein bisschen anders als die Klassifikation der Hersteller aber es gibt diese Automationsrolle das bedeutet dass der Server dafür verantwortlich ist was er mit Input und Output Modulen macht die deinen Kraftwerk-Equipment steuern zum Beispiel in elektrische Steuerung und die letzte Rolle ist die Kommunikation in dieser Rolle diese Rolle wird benutzt um Verbindungen herzustellen zu Trittpartei-Software zum Beispiel Protokoll Konverter den Modbus oder IC101 und so weiter und die letzte Rolle ist die Migrationsrolle diese Rolle wird benutzt um ehemalige SPPA Versionen zu verbinden und andere Legacy-Systeme wie zum Beispiel SPA, T2000 oder andere die Automation Rolle kann man auf Simatik S7 PLC laufen lassen oder einem industriellen PC die anderen auch lassen uns über die Rollen einzeln mehr reden anders mit der Automationsrolle auf dem PLC an der man kann damit direkt Turbin z.B. steuern und Zukunft darauf haben und die repräsentieren üblicherweise die niedrigste Stufe verschiedener Referenzmodelle zum Beispiel ein bestimmtes Modell Update oder Rechte die nötig sind um ein Prozess zu starten oder zu stoppen diese Geräte haben also immer Misskonfiguration Security Updates und unsichere industrielle Protokolle in dem Fall zum Beispiel gibt es S7 Protokolle Es gibt Informationen über diese Protokolle im Internet, aber nicht so viel über das PLC Data Protokolle d.h. wir mussten das selbst analysieren und das ist kein spezielles Protokoll für SPPA und das wird für den PLC benutzt und für die Datenaustausch in Echtzeit um wird dieses Protokoll benutzt und das ist ein ziemlich einfaches Protokoll Vielleicht ist die Beschreibung irgendwo im Internet verfügbar aber wir haben es nicht gefunden also hier sind jetzt erstes im Internet ist es gibt eigentlich keine Sicherheitsmechanismen in diesem Protokoll es gibt nur das einzige Internet während der man in the middle als Angriff um die Daten zu spufen war eigentlich nur die Sequenznummer die wir einfach von einem Paket klauen können um das Protokoll zu analysieren haben wir einen Deceptor gearprogrammiert, der auf dem Link verfügbar ist als wir das analysiert haben war eine der wichtigsten Sachen die wir checken unautorisierte Zugriff auf die Speicher von dem PLC und zwar lesend uns schreiben und der Zugriff ist von der Position des Modselectors des PLC abhängig und einem anderen Konfigurationsparameter und als wir Forschern geforscht hatten von oder aus unser Kollege Daniel Pattercheff da hatten wir schon den Zugriff darauf bekommen die haben gezeigt, dass diese sicheren Zustände und Konfigurationen der PLCs bearbeitbar können sind, das heißt das Tool um diese Sachen zu verändern wurde von Daniel entwickelt und es ist auch in unserem Repository verfügbar sprechen wir jetzt mal kurz über die Applikation basierend auf dem PIP es am Anfang versucht es einige weitere Dateien vom Applikation Server herunter zu laden und diese Dateien sind Jar Dateien, Bash Scripts Konfigurationsprotokolle und so weiter um die auszuführen die Jar Files benutzt einen PTC Perk Virtual Machine als Ja Virtual Machine und das wird wir den verschiedenen Bereichen z.B. auch Internet of Things benutzt das enthält einen Ahead of Time Komplierungsmechanismus und Byte Code Transformation und deswegen können wir da nicht normal decompilieren wie wir anders und anderen Javascripten machen, aber wir haben ein PRP Script entwickelt um diese Transformation durchzuführen und danach können wir dann den Code decompilieren die Jar werden ausgeführt und die RMI Services werden ausgeführt und auch die RMI Extension wird ausgeführt also die Arian RPC Services die klassischen RMI Services werden benutzt und auf dieser Slide sehen wir die Liste der verfügbaren Services Sicherheitslücken hier basiert auf dem Industrial PCPP System also zum ersten Mal können wir die heruntergeladenen Dateien ersetzen oder felschen weil da ist keine Sicherheit dabei keine Sicherheitsmenace zweitens sind da Standard Logins drin mit denen kannst du sehr einfach über SSH Zugriff erhalten auf diesen Server mit Benutzter CM Admin weiterhin sind das Verwundbarkeiten in RMI RPC Services das erlaubt uns für verwundbare Daten herunterzuladen und auch Code auszuführen und weiterhin haben wir verschiedene Verwundbarkeiten in der Software gefunden in SP4A 2000 und später mit einigen Problemen in diesen Servern mit einem alten TXP und das ist echt ein Problem wenn ihr mehr wissen wollt über die Orion RPC Verwundbarkeiten wissen wollt das sind zum einen die Vulnerable Services also der Server hier ist verwundbar da benutzen wir hier die Request runtime Container Methode und dort wird das nämlich ausgeführt was wir da als Argument angeben damit können wir Dateien vom ganzen System auslesen mit ihrem WriteConfig mit der WriteConfig-File können wir auch Sachen auf den Server schreiben und das könnte auch eine Jar-Datei sein die wir dann normalerweise bei der Commander-Zeit ausführen und wir können natürlich auch SP4A Funktionen ausführen und damit diese Jar-Datei später ausführen und das ist also was wir über den Automation Server gelernt haben der kann also auf PLC oder Industrial PC basieren können dann wenn es PLC ist dann ist es der ganz normale PLC mit keinen Sicherheitsproblemen aber wenn es ein Industrial PC ist dann ist es einfach nur eine Linux Box die irgendwelche weiteren Daten vom Application Server herunter laden wird und die dann ausführen mit der Perk Virtual Machine jetzt haben wir noch gar nicht darüber gesprochen über das ganze Netzwerk das ist eine Netzwerksausrüstung in diesem System und als wir geforscht haben haben wir viele verschiedene Netzwerkeräte gefunden und viele verschiedene Netarten von Netzwerkeintracht, Netzwerkinfrastruktur wie zum Beispiel Switches, Firewalls oder auch seltenere Geräte wie zum Beispiel eigentlich verstanden wir haben jetzt mehr eine Karte von verschiedenen Netzwerktopologien oft in SPPA benutzt und wir haben den normalen Ort von diesen Devices getan aber die können auch woanders gefunden werden die Netzwerkeräte in den industriellen Netzwerken haben normalerweise viele Sicherheitslücken die meisten brauchen keine Konfiguration bevor sie starten und können einfach so direkt out of the box benutzt werden und das heißt dass die SNMP Community Strings so erratbar sind die Firma ist möglicherweise mit öffentlich verfügbare Exploits und generell sie haben die nicht besonders viel Sicherheitskonfiguration und all diese Sachen sind noch üblich für Netzwerkeräte und und das gibt halt die üblichen Sicherheitslücken von diesen industriellen Einsätzen und das ist alles und jetzt gibt es noch die Zusammenfassung ok also das Thema Power Kopfwerke ist echt groß das System ist riesengroß wir haben das versucht hier und da mal ein bisschen was zu behandeln alles ist irgendwie auf dieser Folie zu sehen es zeigt ein Haufen Schwachstellen Probleme in Java in Web-Anwendungen in anderen einfach Mechanismen um noch nicht mal in die PLCs rein zu müssen oder in das Feldlevel zu müssen aber man kann schon den Prozess beeinflussen und behandeln was wir nicht behandelt haben ist wie ein ein Disaster erstellt werden könnte wenn man gut ausfüllt das ist nämlich, also es ist nicht so schlimm ich habe natürlich Sachen gehört wie Stromausfall in der ganzen Stadt das ist nicht was du hier mitmachen kannst das Problem der Power Generatoren da gibt es natürlich Regulatoren die die Elektrizität zu den Kunden verteilen also worüber wir hier wirklich reden ist nicht ist wie wir die Turbinen beeinflussen können also die Turbine selbst beeinflussen können wir haben aber keinen Zugang zu einer richtigen Turbine gehabt also sie sind sehr groß und teuer und niemand wollte uns Zugang zu seinen geben damit wir sie zerstören können es ist also so was wie eine gebildete Vermutung diese Turbine ist ein riesengroßes mechanisches Monster was sich selber zersetzt bei der Arbeit und wenn man das in unterschiedliche Modi setzt dann machen wir es im 12h schneller kaputt wir verwitzen es ab also du hast da in der Regel keinen Ersatz Turbine also man kann schon Einfluss haben aber es ist nicht ein riesengroßes Einfluss was wir versucht haben zu machen mit unserer Forschung ist wir wollten verstehen wie wir den Kraftwerkbetreibern helfen können Fehler zu finden die Infrastruktur zu analysieren und all diese Installationen sind ziemlich ähnlich und wir können ein einfaches mach es selbst Test-Assessment schreiben und vielleicht gibt es ja Ingenieure an den Kraftwerken die das dann selber testen können ein Satz von Schritten auf zwei oder drei Seiten du kannst zum Applikations selbstwerk laufen verbinden und die Tests laufen lassen auf dem Automationsserver verbinden und die Tests laufen lassen die teure Consultants mieten dieses machen du solltest in der Lage sein das selber für dich als Kraftwerkbetreiber umzusetzen aber natürlich um die Situation zusammenzufassen rund um DCS wenn man andere industrielle Lösungen gesehen hat alles was man so sehen kann dann wird man viele Sachen sehen die ähnlich sind dieselben Schmerzpunkte und vielleicht bei anderen Lösungen aber es gibt einen guten Dokument von ARC 62443 wie sie mit den Systemindikatorn und Herstellern reden sollten welche Security manchmal dass man sie brauchen und wie sie sie umsetzen sollen für Kraftwerkbetreiber wir können nur allen Kraftwerkbetreibern empfehlen diesen Standard zu lesen wie von ihren Herstellern einzufordern weil Hersteller im Zölfe mittlerweile schon mehr um Sicherheit bedacht ist also wenn man nicht weiß was man machen soll dann ist das das Dokument das beschreibt wer mit wem über was wir reden sollte und natürlich kannst du diese Slides und das Wallpaper lesen das kommt im Januar raus Ruf Siemens an macht deine Systeme aktuell in deinem Passwort das sind einfache Schritte um den Angriffswektor oder dein Angriffsoberfläche zu verkleinern eine andere Sache Modern Windows Boxes ist es also einfach damit Monitoring aufzusetzen und du solltest mit deinem Sicherheitszentrum reden und dann sollten die in Locks angucken können die meisten Sachen kommen von Java-Applikation und man wird es nicht möglich sein irgendwie Locks komplett zu bekommen aber man könnte vielleicht ein paar Erkundungsmechanismen im Netzwerk haben und nochmal um zusammenzufassen das ist kein Problem von einem DCS von Siemens das ist überall in anderen Herstellern genauso auch Hersteller die wir jetzt hier nicht genannt haben wir werden ein paar Sachen veröffentlichen heute und morgen und im Januar im Wesentlichen das große Wallpaper über alles was wir rausgefunden haben mit Word-Listen mit Selber-Mach-Sicherheits-Guide-Line welche welche Tools und Werkzeuge wir benutzt haben für unsere Forschung oder wenn du selber die Protokolle angucken möchtest wir haben sehr mit Siemens zusammengearbeitet wir wollen da Danke sagen die haben einen großartigen Job gemacht mit der Kommunikation mit uns und dem Team was deren Produkte entwickelt die großen Sachen von den Antworten der Hersteller ist wenn du ein Kraftwerkbetreiber bist dann bist du echt genötigt jetzt schnell ein neues Version zu aktualisieren Siemens versucht die Leute zu bilden und Bewusstsein dafür zu schaffen bei unseren Kunden dass sie die Passwörter ändern sollten dass es kritische Verwundbarkeiten gibt und dass man da aktiv werden muss und nicht alle Probleme sind von Siemens selbst behandelbar aber der Betreiber des Kraftwerks muss da manche Sachen selber in die Hand nehmen okay, das ist vielen lieben Dank dass wir hier sein durften wenn ihr Fragen habt dann ist jetzt eure Gelegenheit hier wir haben noch 3 Minuten für Fragen wenn du Fragen habt dann bitte an die Mikrofone wenn ihr Hörhilfe benutzt es gibt hier am Mikro 3 eine Entdeckungsschleife okay, da gibt es eine Frage aus dem Internet vom Signal Angel okay, wir haben eine Frage könntest du manche dieser Sicherheitslücken aus dem weltweiten Internet ausführen ohne okay, sorry die Schwachstände, die ihr gefunden habt könntet ihr den einen Kraftwerk kontrollieren aus dem öffentlichen Internet heraus ohne weitere Männendemittelankriffe nein, das ist eine Sache der guten Nachrichten diese Systeme sind immer nur von einem Systemindikator betrieben die sind also mehr oder weniger vom externen Netz geschützt also natürlich gibt es irgendwie Schnittstellen aber das ist nicht so einfach wir reden ja dann über nicht das Internet, sondern über Netzwerke der Firmen nächstes Frage für Mikro 3, ja hallo ich habe auch ein Kraftwerk auf meinem Planet und es ist vielleicht schlecht für die Atmosphäre meine Frage ist könnten wir zurückgehen wo der rote Knopf ist und das Kraftwerk ausschalten könnte ich frage nur für einen Freund wenn ich gehört habe dass du dieses Material in dieser Art und Weise benutzen kannst dann wenn du Operatoren und Betreiber von Kraftwerken kennst dann kannst du ja zu diesen gehen und es fragen gibt es noch weitere Fragen ok, das war es dann vielen Dank für den Vortrag und helft uns die Speaker mit einem hessischen Applaus zu beobachten