 Siemens hat vor kurzem eine paar neue Sicherheitsfeatures, die ihre Sprecher programmierbaren Steuerung hinzugefügt. Sie werden uns ein bisschen erzählen darüber, was sie dabei gefunden haben. Sie kommen aus der Universität Bochum. Sie studieren da und leeren da. Und eine große Applaus für unsere beiden Vortragenden. Wir kommen zu unserem Vortrag. Wir können auch was anschauen von unkonzentrierter, von voller Kurtausführung auf den Siemens S7 Sprecherprogrammierbaren Steuerung. Wir sind aus der Udi Bochum und ich bin Tobias. Ich bin fünfmal auf dem Congress und jetzt kann ich endlich zurückgeben und ich bin da sehr froh drum. Lass uns jetzt damit anfangen. Zuerst worum geht der Vortrag? Wir haben ein bisschen Hintergrund für euch, wie Sprecherprogrammierbare Steuerung funktionieren, was sie machen, warum wir sie vielleicht nutzen wollen, in welchen Umgebungen. Dann werden wir uns genauer anschauen, welche Sprachsspessen von Siemens verwendet werden, die Hardware von ihnen und danach die Software und die unterschiedlichen Sachen, die wir dabei gefunden haben. Zu guter Letzt wollen wir ein Beispiel zeigen, was wir erreicht haben und ein paar Informationen geben. Zu allererst Prozessautomatisierung. Wir alle kennen jemanden, der es macht. Wir nehmen ein Gerät, in unser Smart Home, wenn wir es nennen wollen, smart nennen wollen. Und wir automatisieren unterschiedliche Ziele, unterschiedliche Sachen, um unser Leben einfacher zu machen, wie zum Beispiel die Temperatur weiter auf und abdrehen. Wir wollen nicht zu heiß werden und nicht zu kalt werden. Was wir sagen, ist, Sie nehmen ein Sensor in unserem Haus und ein Gerät, das mit diesen Sensoren interagiert. Zum Beispiel haben wir ein Thermostat und eine Heizung. Und wir wollen die Temperatur so anpassen, wie es im Thermostat eingestellt ist. Sehr einfache Lösungen, wie das hier für Smart Home. Aber was ist, wenn wir ein sehr komplexes System haben? Hier können wir sehen links unten ein ziemlich komplexes Bild, wo ein paar Operatoren vor einem Bildschirm sitzen, einem Computer-Maschinen-Interface, die die ganze Information anzeigt, was zum Beispiel in dieser Fabrik passiert. Wir haben unterschiedliche Sensoren in der Fabrik. Und wir müssen unterschiedliche Motoren steuern, sodass... Und dafür benutzen wir programmierbare Steuerung, speichere programmierbare Steuerung. Wir haben unterschiedliche Inputs und Outputs und wir haben eine Logik dazwischen. Und normalerweise benutzen wir eine SPS, eine speichere programmierbare Steuerung. Und unterschiedliche Technologien, die da verwendet werden können, zum Beispiel ein Programm oder Bilder, die unsere grafische Programmier-Interface-Mutzoptionen und die steuern dann den Output abhängig davon, was sie hereinbekommen haben. Zum Beispiel chemische Anlagen oder Stromsteueranlagen oder bei der Autoherstellung. Dort sind sie sehr kritisch zu dem, wie unsere Umgebung funktioniert. Manchmal sehen wir sie nicht, aber sie steuern alles im Hintergrund. Und wir wollen wirklich nicht, dass sie missbraucht werden. Wenn man zum Beispiel zu Google geht und Chemie-Desaster anschauen, dann können wir sehen, wie das aussieht. Und wir wollen nicht, dass das passiert. Weder aus Versehen noch, weil jemand es zerstören wollte. Hier sind ein paar der Angriffe in der letzten Zeit. Es begann 1999 mit dem ersten Erkundungsversuch. Und später wurde es dann fortgeschritten, 2010 zum Beispiel, wo das DAXnet gefunden, der ein sehr komplexes System war, was sie da alles benutzt haben, welche unterschiedlichen Fähigkeiten dafür verwendet wurden. Es war sehr eindrucksvoll. Und in den letzten Jahren hatten wir einfach Probleme mit den ukrainischen Stromversorgungen. 2015 und 2016, kurz vor dem Weihnachten, es ist Licht in einigen Städten für sogar eine ganze Weile ausgefallen. Ein paar Ideen für Siemens. Speichern wir über die Steuerung und zu reden. Zusammen mit Rockwell-Automation ist Siemens mehr als 50 Prozent der Marktmacht. Und wenn wir dort Geräte haben, die ein bisschen mehr Sicherheit haben, dann wollen wir uns anschauen, die anschauen, die am häufigsten verwendet werden. Darum haben wir uns auf Siemens eingesteuert. Dies ist die Siemens S7 1200. Speichern wir über Steuerung. Das ist eine der kleineren Siemens Steuerung. Es gibt noch kleinere, aber das ist mir so ein Beispiel. Das ist das, was wir die Kammern als relativ bezahlbar sind. Es sind 250 Euro für die PLC, aber auch noch ein bisschen Strom. Das kostet noch mal so viel. So lange man nicht zu viel kaputt macht, wir haben ein paar kaputt gemacht und man sie nicht fallen lässt oder solche Ansachen, dann funktioniert das ziemlich gut. Man kann irgendwoher die Ressourcen bekommen, um damit zu spielen. Wir haben unterschiedliche Anwendungen und die haben wir vorhin schon besprochen. So sieht es im Inneren einer Siemens S7 1200. Speichern wir über Steuerung. Wir haben den Blick von oben. Im linken Bild ist nur eine von mehreren Platinen, die beieinander ins Gehäuse sind. Aber die wirkliche Magie passiert in der obersten Platine, die Grüne, die wir jetzt hier sehen. Wenn wir das Ganze ein bisschen detaillierter anschauen, dann haben wir oben den Blick von oben, der linken Seite, den Blick von oben, die Arm-CPU, die da drin läuft, unterschiedliche Input- und Abput-Sachen, die wir miteinander kommunizieren, damit unterschiedliche Systeme gesteuert werden können. Und dann ist der Flash-Chip dort auf der oberen Seite. Es ist ein großerer Flash-Chip, der die Firmware der Steuerung beinhaltet. Und die werden wir uns später genauer anschauen. Auf der Rückseite ist die Unterseite der Platine. Hier ist der Chip, auf dem der Bootloader ist, ein SPI Flash-Chip für Megabytes, wo der Bootloader liegt. Hier wollten wir uns mal genauer anschauen, was für ein Prozessor auf dieser Platine drauf ist und wie der aussieht und wie wir das wirklich herausfinden wollen. Wenn man es wirklich herausfinden möchte, muss man den Chip aufmachen, die Capsulesen und es ist ein Renesers Arm-Cortex A4 aus dem Jahr 2010. Wenn wir jetzt Software uns näher anschauen, dann wollen wir auch herauswissen, welche Versionsnummer das ist, welche Arm-Standard unterstützt wird und wir haben eine spezielle Instruktion im Arm-Instruktion-Set und dann können wir die unterschiedlichen Bits inkludieren. Und wenn wir wirklich herausfinden wollen, was passiert, können wir diese Bits analysieren und genau die Hardware herausfinden, die dort verwendet wird. Und damit wenden wir uns dem Speicher der Hardware zu. Und da übergebe ich jetzt an Ali. Ja, also jetzt nach dem Tobias, den die SPS ausgepackt hat, werde ich mir jetzt ein bisschen die Features angucken. Wie wir vorhin schon gesagt haben, es ist ein Cortex A4 Revision Nr. 3. Das ist ein Big-Indian Befehlssatz. Und das hat auch nur eine MPU, also es gibt keinen virtuellen Speicher, verschiedene Größe von Arbeitsspeicher. Das hängt davon ab, in welchem Jahr man das gekauft hat und was für eine Version der Hardware man bekommen hat und auch verschiedene SPI-Flesch und Nand-Flesch-Chips. Die wichtigste Unterschied ist der Arbeitsspeicher. Die Neueren benutzen Micron Technologies. Und wir schauen uns mal hier den SPI-Flesch an für den Bootloader. Und abhängig davon, ob man eine oder vier Megabyte SPI-Version hat, hat das unterschiedliche Menge an Speicher. Und was der Bootloader jetzt macht, macht die typischen Sachen, was ein Bootloader so macht, also die Hardware konfigurieren, verifiziert, ob das Framework korrekt ist, bevor es geladen wird. Und wir haben das mit Röntgenstrahlen durch uns angeschaut. Das ist also dreidimensional, das heißt, die Platine rotiert. Wir wollen uns hier auch die Hardware genauer angucken. Und jemand an der Universität hatte so ein Gerät. Also hier ist eine schnelle 15 Minuten Röntgenbild. Aber wenn man sich das dann genauer anschaut, tiefer reingeht, dann bekommt man sowas. Und das ist so eine Art Software-Animation. Also man kann da auch in die Platine reingehen und jede Schicht einzeln sehen. Das ist sehr nett. Das hat also vier Schichten. Also schauen wir uns den Boot-Prozess an. Es wird üblicherweise, also wie üblich, passiert Hardware-Konfiguration. Da gibt es ganz viele Modus-Händler. Und dann wird eine CRC-Prüfzumme berechnet, die man leicht umgehen kann, indem man einfach die CRC umgeht. Die 2017-2018-Variante erlaubt uns da, diese SPI-Flash zu überschreiben. Und letztendlich auch die CRC-Check-Summe des Frameworks wird dann auch geprüft, bevor es geladen wird. Das sind 128 Kilobyte. In Wirklichkeit ist es weniger. Die Hälfte davon ist im Wesentlichen nur Nullen. Siemens hat das mehrfach geändert. Da gibt es verschiedene Versionen, drei Varianten, vier Varianten von diesem Boot-Loader. Das hat sich also weiterentwickelt. Das war also nichts, was statisch war. Wie wird das schon erwähnt haben? Erste Stufe ist Hardware-Initialisierung. Und dann wird der Boot-Loader in den Rahmen geladen im Wesentlichen und die CRC-Prüfzumme überprüft. Damit er nicht verändert wurde, was man aber leicht umgehen kann. Und die zweite Stufe, da wird dann die Hardware, also das ist die zweite Stufe der Hardware-Initialisierung. Und dann wartet das eine halbe Sekunde auf ein spezielles Kommando. Und da reden wir nachher drüber, was passiert, wenn man dieses Kommando da reinschickt. Und ansonsten erzeugt das CRC, also Prüfzummen-Tabelle und die blendet dann quasi das Framework im Rahmen ein. Das Betriebssystem hatten wir bislang nicht erwähnt, das heißt Adonis. Wir kennen das aus anderen Kontexten. Die ersten Referenzen dazu sind im Framework enthalten. Das war uns aber nicht genug. Wer mal so gesucht, gibt irgendwie Referenzen da drauf. Und bei LinkedIn kann man sowas gut nachschauen. Und hier gibt es jemanden, der ein Siemens-Entwickler, der schreibt, dass er hier mit Adonis gearbeitet hat, also er hat damit gearbeitet. Und das war nicht genug für uns. Also weiß auch nicht, warum der Davinos und Linux danebenschreibt. Und wir gucken nochmal weiter. Und dann gibt es den hier. Das war der beste Indikator dafür. Da hat ein Siemens-Engineur geschrieben, dass er mit Adonis Real-Time Operations System gearbeitet hat. Und das heißt, wir haben also Recht. Und jetzt kennen wir also den Namen und sind uns auch sicher. Und jetzt schauen wir uns mal die Komponenten an. Es ist in 440 geht es los. Und dann wird der Kernel initialisiert. Und dann gibt es viele verschiedene Routinen, um die einzelnen Komponenten zu initialisieren. Ich glaube nicht, dass Siemens das so darstellt. Wir haben keine Bilder. Das heißt, wir haben das aufgeteilt jetzt in Kernendienste. Und dann gibt es solche, die mit der Automatisierung zusammenhängen. Also sowas wie Logikprogramme, Befehle, die dann auch tatsächlich zur Verfügung stehen. Das sind mehr die Dienste, die mit Automatisierung zutun haben. Profinet, AWP, automatisiertes Web-Programmierung, den MC7P-Paser und die weitere Logik. Die einzelnen Teile haben da ihre eigenen GIT-Kompiler innerhalb des SPS. Und dann gibt es das OMS, das Konfigurationssystem, was sehr viel mit Automatisierung zutun hat, mit diesem Kernautomatisierungssystem. Und dann gibt es Central IO Alarm und solche Dinge, die mit Automatisierung zusammenhängen. Im Betriebssystem Teil gibt es die üblichen Sachen, also Datei-System, PDC-FS, da wird Tobi später noch drüber reden. Der TCP-IP-Stack, einige C++-Bibliotheken, die nicht von Siemens kommen. Mini-Webserver, ein MWSL-Paser, viele Unterkomponenten, das ist ganz üblich in Betriebssystemen. Ja, und es gibt auch Verweiser auf Core-Site, ich weiß nicht, wie viele da Core-Site kennen oder damit arbeiten. Das ist so was Ähnliches wie Intel-PT, also Intel-Prozess-Chasing für Intel-Applikationen. Und das kann man benutzen, um Code-Abdeckung zu erreichen, zum Beispiel der Hardware-Teil, das ist von Thomas Weber sehr gut dokumentiert, der ist auch hier, also dieses Jahr hat er auf Blackhead Asia vorgestellt. Aber Vorsicht, wenn ihr euch damit verbindet, die SPS hat Anti-Debugging-Features, die dann den NAND-Flash mit zufälligen Daten überschreibt. Also da macht ihr die SPS kaputt. Also gucken wir uns Core-Site ganz kurz an. Bevor ich mir das jetzt mache, also Ralph Philipp hat auch eine super Talk über Core-Site-Chasing, also ich empfehle euch den mal anzuschauen. Core-Site hat drei Hauptkomponenten, Quellen, Verbindungsteile und Senken. Und der erste Teil ist ein Feature in der CPU, wo man der CPU mitteilt, woher man die Daten haben will. Diese Verbindungen, die links, die konvertieren in gewisser Weise diese Quellen. Das kann man auch gut zum Fasen benutzen. Ein paar Leute, also nicht viele, arbeiten damit. Also Coverage-Guided-Fuzzing, das gibt es auch bei Intel-PT. Und diese Quellen, die haben wesentlichen drei Komponenten, STM, PTM und ETM. ETM nur in der neuesten Version. Und man hat da also diese links, diese Verbindungen, die verschiedene Quellen zu verschiedenen oder einzelnen zu solchen Ausgabemodulen verbinden. Also es gibt da diese Senken. Und wie zum Beispiel den Ringbuffer der CPU oder JTAG oder die internen Daten-Fahde. Dann haben wir uns angeschaut, ob Core-Site vorhanden ist. In der Software ist es schon implementiert. Das heißt, sie haben die Referenzen in ihrer Software drinnen, wo Core-Site in der SPS konfiguriert wird. Und es ist eine ältere Version, das ist die Version 3. Jetzt, als wir über Core-Site geredet haben, schauen wir uns Firmware-Dumps an. Das ist jetzt etwas, mit dem ich viel mehr gemacht habe, was für mich eher zu Hause für Firmware-Dumps in diesem Fall, dass es so nah wie möglich war, daran kommt, was ich mag, wenn wir über SPSen reden oder darüber reden, wie SPSen funktionieren. In Siemens Fall haben wir dieses 13-Megabyte Binary. Im Anfang ist es nicht so groß, aber wenn man damit sich das Ganze anschaut und die Python-Funktion darauf anwendet, dann kommt man 84.000 Funktionen. Die möchte man sich nicht alle genauer anschauen müssen, also zumindest nicht manuell. Außerdem haben wir auch 84.000 Funktionen in einem Image. Das ist auch nicht die schönste Firmware, die es auf der Planet gibt. Aber das ist, was ich mir angeschaut habe. Das ist auch, was wir uns jetzt in den nächsten paar Minuten genauer anschauen wollen. Wir haben unterschiedliche Namen. Ein Name, Sum, Get, Sum, Max, Salz, das ist mein interner Name. Ich verstehe nicht wirklich, was es macht in dieser Funktion, aber es gibt andere, die besser benannt sind. Ein paar Teil haben wir besser verstanden, ein paar Teil haben wir schlechter verstanden, ich habe in viele die meisten Stellen mal angeschaut. Jetzt geht es um die Adressen. Wir haben viele Informationen darüber herausgefunden, viele Sachen herausgefunden, die interessant sind, wenn wir uns den Code in der Firmware anschauen. Was wir zuallererst verstehen müssen, ist, dass der Codex M0 Bank Register gibt. Man hat verschiedene Bänke, wo Register in der CPU logisch vorhanden sind. Das ist ein einfaches Software zu schreiben. Wir haben unterschiedliche Banken pro Ausführungsmodus. Das heißt, den wir uns anschauen wollen, was in den Firmwarestatus zu einer Zeit, wie der in den Firmwarestatus aussieht, ist, da müssen wir uns anschauen, wie die Statis der unterschiedlichen Modi sind. Das ist der Firmware, den wir uns angeschaut haben, und die können wir uns anschauen, und als Anfangspunkt für eine Reverse Engineering benutzen. Jetzt haben wir ein paar Adressen. Der erste ist der Arbeitsspeicher. Die zeigt, welche Funktionalität, was man erwarten kann, wenn wir Firmware Code uns anschauen. Das sind die Interfaces in unterschiedlichen Arbeitsspeicherbereichen. Wenn wir uns Armcode anschauen, dann sieht das irgendwelche komische Zugriff auf irgendeinen Arbeitsspeicherplatz, und wir wollen wissen, was es da wirklich macht, und es sieht sehr univentvoll aus, wenn da irgendwie ein Arbeitsspeicherzugriff ausgeführt wird. Man hat keine Ahnung, was es macht. Zum Beispiel in einem Bereich, da ist Code, und wenn man irgendwelche globalen data anschauen möchte, dann muss das Data oder BSS-Sektionen anschauen. Und Heapmemory ist auch in seinem eigenen Arbeitsspeicherbereich, bei Heapmemory im uninitialisierten Bereich. Und für unterschiedliche Sektionen wird diese Daten zusammengetragen. Wenn man sich Firmware-Images anschaut, möchte man auch wissen, welch Hardware ein bestimmtes Bereich von Code interagiert. In diesem Fall haben wir die Regionen angeschaut, oder herausgefunden, was sie unterschiedlich in Regionen bedeuten für Arbeitsspeicher gemäppten IO. Arm arbeitet mit der Hardware in einer Art und Weise, dass da ein Bereich in der Erfahrung ist, und in denen werden Daten geschrieben oder Daten gelesen, und das wird dann zu einem Ausgangsdaten vom Chip, irgendwelche Beinchen- oder Binärdaten am Chip analysiert. Wir haben unterschiedliche Chips, mit denen wir reden können, mit unterschiedlichen Serielprotokollen, zum Beispiel SBI oder SQC. Und da steht, wo diese Verbindungen im Arbeitsspeicher abgelegt sind, oder logisch verknüpft sind. Zum Beispiel gibt es Timers, die angesprochen werden. Und damit versteht man auch, wo mal was in dem Code ungefähr passiert. Haben wir Sicherheitsmodi? Siemens nutzt einige von diesen Konfigurationen, um Arbeitsspeicher zu schützen, zum Beispiel, wenn das Eclicute Leverbit gesetzt wird, dann wird das nie ausgeführt in diesem Adressbereich, oder wir haben Bereiche, die man nur lesen kann, die nicht überschrieben werden. Das heißt, es ist interessant, dass sie das in Praxis angefangen haben, anzuwenden. Hier sehen wir, was passiert, wenn die Firma selber bootet. Die Firma möchte nicht wirklich zu sehr vom Firma abhängen, und da gibt es wahrscheinlich unterschiedliche Teams, die unterschiedliche Dinge tun, und das Interface zu klein, wie möglich zu machen. Wiederholen Sie ein paar Sachen, die der Bootloader-Coach schon gemacht hat. Das heißt, er stellt die Vector-Tabelle für Interrupts und so weiter. Wenn wir jetzt weitergehen, wollen wir den Adonis-Colonel starten. Und das Erste, was wir da machen, ist ein Array von Funktionspointer. Einen für jede Funktionalitätstyp, den wir vorhin gesehen haben, in den unterschiedlichen Adonis-Komponenten. Das heißt, wenn man sich anschauen möchte, welche Komponenten sind da, welche Funktionskomponenten sind vorhanden, dann haben wir hier schon mal einen Anfang, wo wir da auch ein paar Management-Sachen und Betriebssystemsachen, und so, dass es ein normales Betriebssystem auch macht. So, jetzt haben wir uns die unterschiedlichen Komponenten von der Adonis an. Das ist eines der Teilsystemen, programmierbare Speicherprogrammierbare Steuerung, haben immer so die Frage, wie unabhängig von der Umgebungstemperatur sie sind. Welcher Temperatur kann einer SPS leben, bevor es abstürzt? Und wir wollen auch ein bisschen Sicherheit haben gegen Interrupts, wenn die Stromversorgung nicht so gut ist. Darauf haben sie ein spezielles Betriebssystem, Powered-on-consistence-Dateisystem, Powered-down-consistent-Dateisystem, das ist in der Firma definiert, und hier ist auch ein internen, der gesagt hat, dass er an dieser Dateisystem gearbeitet hat. Wir haben noch einen weiteren sehr kritischen Teil von der Funktionalität. Wir wollen mit der SPS reden, wir wollen, dass die SPS mit uns reden kann, und eine der Adon und Weisen ist TCP-IP, also Netzwerk, und wir haben unterschiedliche Komponenten erreichbar gemacht, und Siemens hat hier nicht sein eigenes Set-up, was eigentlich eine relativ gute Idee. Sie benutzen den TCP-I-Stick von Interneesh. Wenn man googelt, kann man den Source Code finden, und wenn man den in der Firmware übertragen kann, dann kann man einige Zusammenhänge sehen, oder kann man bei grundlegenden Funktionen finden, wie man einen Socket erstellt wird, und das einfach diese Funktionen im Firmware mitzufinden. Wir haben auch einen sehr kritischen Komponenten von jeder Firma, das ist wie es updated, und die Siemens PLC ermöglicht, das eine ist man drag-and-dropt, einen UPD-Datei, ein Update-File in den Webserver, und der versucht dann die Firmware Integrity zu überprüfen und die Signaturen zu überprüfen, und der andere Weg ist, mit einer SD-Karte zu machen. Die hat 24 Megabytes und kostet nur 250 Euro. Das ist super günstig, also so günstig. Wenn die SD komprimiert, so ein UPD-Datei komprimiert, dann hat man, wie es im Arbeitsspeicher aussieht, man hat unterschiedliche Fälle, die man sich hier anschauen kann, und das sind unterschiedliche Offsets, wo man in das Binär-Datei eingreifen kann, einspringen kann, und ein magischer Header, das nicht immer was ganz komplett ist, und eine CRC, das ganze, den ganzen Header. Wir haben auch ein paar Adressen aus dem Firmware-Match auslesen können, die uns dabei helfen, wo man in die Logik einsteigen kann, und das schauen wir uns später an. Der nächste Komponente ist Miniveb, der Webserver. Der zeigt einem in gewisser Weise die internen Teile der SPS und welche Zustände die verschiedenen GPIOs haben, was die Eingaben sind, was die Ausgaben sind, und das macht das mit einem MWSL Sprache, also die Minivebskripsprache, und wir werden das auf der nächsten oder die übernächsten Folie werden wir das sehen, da werde ich dann auch gleich noch mal Detailier drauf eingehen. Es gibt ein Dienst, eine von diesen Adonis Initialisierungsfunktionen, da habe ich vorhin auch schon drüber gesprochen. Jetzt schauen wir uns mal ein paar undokumentierte HTTP-Händler an, das finde ich ganz interessant. Also li-li-li-li-li und lo-lo-lo sind meine Lieblinge. Wenn man die zusammen baut, wenn jemand vielleicht musikalisch inkliniert ist, dann kann man da vielleicht ein Lied draus bauen. Finde ich ganz interessant. Also schauen wir uns mal diese MWSL, diese Skripsprache an, die die interne Funktionalität nach außen anbietet. Da kann man mit verschiedenen Editorien Dinge in so ein Template einbauen. Da sieht man hier rechts oben. Da kann man zum Beispiel die CPU-Last sehen. Das scheint nicht zu gut zu performen. Es scheint die Ausgabe nicht nicht zu enkoden, also das scheint dem zu vertrauen. Da gibt es also möglicherweise Web-Tricks, die man benutzen kann und auch das Paasen von dieser Darstellung, von diesen Tokens ist relativ komplex. Da wäre es vielleicht auch interessant, sich die Implementierung anzugucken. Wir werden uns diese Sachen auch gleich noch später anschauen. Das heißt, jetzt gehen wir uns erstmal zu den Sachen, die wir tatsächlich gefunden haben und hier spricht nochmal Ali. Ja, danke Tobi. Also jetzt geht es um die Fähigkeiten, die dieser Bootloader hat, die uns unbeschränkte Codausführung erlaubt. Dieses Feature ist im UART vorhanden. Das heißt, man muss physikalisch Zugriff auf diese SPS haben. Aber wenn man die hat, dann kann man, wie Tobi beschreibt, kann man dieses Sicherheits-Ökosystem, das Siemens entwickelt hat, hier in diesem Produkt umgehen. Also man braucht UART-Zugriff, das hier dokumentiert, die Pins TX-RX und diese UART war vorher schon dokumentiert. Alles, was ich hier jetzt dann auch erwähne, da geht es um Bootloader-Version 421. Siemens hat diesen Bootloader aktiv modifiziert. Das heißt, ich denke, über zwei Jahre haben wir da zwei, drei verschiedene Versionen von diesen Bootloader-Versionen gesehen, die rausgekommen sind. Und es geht jetzt also um diese halbe Sekunde, wo erwartet, auf ein spezielles Kommando, nachdem die Hardware-Konfiguration passiert. Das geht also auf diese S7200 und S71200, S7200 inklusive SE Plus und die S7200 Smart. Siemens hat da hinterher auch ihr Advisory geupdatet, dass es auch andere Produkte betrifft. Also reden wir über dieses spezielle, dieses Zugriffsfeature, was hier passiert. Der Bootloader initialisiert die Hardware und kopiert dann Inhalte des Bootloaders auf ein spezielles bespenziellen Bereich, das Arbeitsspeichers IRAM. Und dann wartet das eine halbe Sekunde auf ein spezielles Kommando. Und wenn es dieses Kommando kriegt, dann antwortet das mit einem speziellen Kommando. Also wenn man den, man muss den magischen String MFGT, also es geht hier wahrscheinlich mit freundlichen Grüßen, also, dann hier eine, und dann antwortet die SPS mit Minus-CPU. Und dann ist es in diesem speziellen Zugriffsmodus und man kann auf, irgendwann kann Kommandos reinstecken, das ist in Adresse 0x-EDF-8 im Bootloader. Also hier ist dieser Client, den wir auch dann im nächsten Jahr veröffentlicht werden. Und da sieht man hier unten 2DE435055, das ist dieses Dash-CPU von der SPS. Und wenn dann auch vielleicht noch über das UART-Paketformat reden, da hat jemand vorhin gefragt, also wenn jemand dieses Kommando reinschickt, dann kriegt man eine ganze Menge Funktionen. Wir nennen die jetzt hier Händler. Und also es gibt solche Dinge, die nennen wir primäre Händler, das gibt 128 Einträge und es gibt auch 3 andere, also 0x80 UART-Konfiguration und BI. Und in den Primären, da gibt es eine ganze Menge Sachen, wenn wir uns die 2 vorherigen Folien nochmal angucken, dann habe ich hier die Version 4.2.3. Und was hier passiert, ist, dass dieses Kommando Get-Bootloader-Version wird ausgeführt. Also wir benutzen einfach dieses Feature, um rauszufinden, wie die Version vom Bootloader ist. Man kann eine ganze Menge Diagnosefunktionen ausführen, auch Framework-Updates, kann man machen, die die übliche kryptografische Verifikation dieses Frameworks umgeht, die braucht das gar nicht. Und jetzt schauen wir uns das mal genauer an. Also wir haben hier tatsächlich nur 2 von den Händlern wirklich benutzt. Wir werden über die anderen 128, die anderen werden wir gar nicht besprechen jetzt hier. Und wie funktioniert es? Einer von diesen, einer der interessant ist für uns, ist 0x80, der ist hier schon erwähnt. Update-Mode-Funktion, was das tut, ist, es erlaubt uns auf eine spezielle Stelle im Speicher, IRAM, zu schreiben, wo vorhin etwas vom Bootloader hingekopiert wurde. Da muss man also diesen Austausch machen, MFGT1, und dann benutzt man diesen Händler und dann prüft es hier die Anzahl Argumente. Je nachdem, was man für ein Händler benutzt, hat es verschiedene Voraussetzungen. Und dann muss man hier in dem Fall eine Target-ID mitangeben. Manche, da geht es um IRAM, SPIO oder Flash. Und für jeden einzelnen muss man dann auswählen, welch was für eine Operation man machen will, konfigurieren, lesen, schreiben, prüfen. Man kann das also machen, man kann also lesen und schreiben auf das IRAM im Wesentlichen. Das ist also 0x80. Und der Nächste ist 0x1c. Da ist auch hier in der Liste, hier seht ihr das. Und das erlaubt uns, im Wesentlichen Funktionen aufzurufen. Diese Funktionen sind im IRAM aufgelistet. Da schickt man diesen Handshake, ist dann in diesem 0x1c-Händler, und dann kann man die ID-Nummer dieser Händler, die wir benutzen wollen, aufrufen. Hier sehen wir zum Beispiel eine ganze Menge Händler, die hier für 0x1c zur Verfügung stehen. Und die Frage ist jetzt, was können wir damit machen? Und bevor ich Tobias Frage, will ich hier im Publikum mal fragen. Trace. Nachverfolgen, ich weiß gar nicht, was das bedeuten soll. Okay. Also, du meinst mit CoreSight nachschauen? Ne, gut, dann fragen wir jetzt doch Tobias. Also, wir schauen uns das dynamisch an, was das mit dem Speicher macht. Das ist tendenziell eine gute Idee, wenn man mit Reverse-Engineering nicht weiter kommt. Aber in diesem Fall haben wir, also ich habe diese Funktionen durchgeschaut und nachgeschaut, was ich damit tun kann. Und ich habe damit also angefangen, nach diesen Spezial-Features zu suchen. Und habe festgestellt, da ist zu viel los. Ich habe das Gefühl, ich verstehe, was es machen sollte, aber es war einfach zu viel. Und diese zwei Funktionen zu kombinieren, können wir folgendes machen. Wir benutzen diesen 0x1c-Händler, der uns Kontrolle über welche sekundäre Listenfunktionen jetzt ausgeführt werden soll. Und die haben wir vorhin gesehen, wird rüber kopiert ins IRAM, im Bootprozess. Und das gibt quasi diesen Funktionenhändler, diese Tabelle zu allem, also jedem in die Hand, der IRAM schreiben kann. Und das haben wir vorhin gelernt, das können wir auch machen, eingeschränkt. Und jetzt schauen wir mal, was wir damit machen können. In der ersten Stufe benutzen wir 0x80, um einen neuen Funktionszeiger zu injizieren. Und dann verschiedene Prüfungen zu bestehen. Die können wir als Eintrag hier mit reintun in diese Tabelle. Und wir können auch Daten da reinschreiben, also Shellcode im Wesentlichen. Und in einer zweiten Schritt können wir dann diesen, diesen indizierten Index benutzen, als Aufruf, um unseren eigenen Payload auszuführen. Das heißt, wir haben jetzt also Codesausführungen im Kontext des Bootloaders, was so privilegiert ist, wie man überhaupt nur sein kann zu dem Zeitpunkt. Und wir können mal sehen, ob wir damit auch spielen können. Also kleine Zusammenfassungen, wir basteln das alles zusammen. Wir bekommen Codesausführungen. Wir werden jetzt also... Also bevor wir jetzt hier drüber reden, was wir da eigentlich machen sollen, wir reden also über diesen Stager-Payload. Den habe ich geschrieben, verschiedene Aufrufe. Es stellt sich raus, dieses Schreiben nach IRAM ist relativ langsam und auch fehleranfällig. Da kann es also auch Fehler geben. Ich weiß nicht genau, was das eigentlich ist. Das wäre ganz interessant, wenn Siemens Ingenieure uns das mitteilen könnten. Aber es sorgt dafür, dass ich also einen kleinen Payload hier injiziert habe, der ein Interface anbietet, mit dem man schnellere Lese- und Schreibzugriffe durchführen kann. Und da dann quasi eine zweite Stufe zu injizieren und das wollen wir jetzt demonstrieren. So, jetzt unsere Demo. Zwar der erste. Die Kommunikation uns anschauen, wie diese Anfrage gesendet wird und das Ergebnis empfangen wird und dieses Stager-Payload funktioniert. Oben ist das rohe Uhrart. Später summen wir rein und unten ist unser Kleint. Wir haben mit dem BLC geredet und die Befehle sendet. Jetzt hat man sein Uhrart und sendet die Befehle und wenn ihr es oben seht, seht ihr da oben, dass das Minus-CPU-Signal kam und jetzt senden wir unseren Stager und der sendet immer nur okay, okay, okay. Und das funktioniert mit der Firmware-Version 2.1. Jetzt machen wir was anderes. Wir lesen die Firmware aus einer funktionierenden PLC und vergleichen das mit der Firmware, die wir heruntergeladen haben. Zuerst entpacken wir die Firmware von Siemens. Nommen wir hier. Ah, nein, wir fangen erst einmal mit SSA-Port-Forwarding. Und wir wissen, ob die PLC überhaupt funktioniert. Ordentlich. Sie sehen nicht irgendwie eine kaputte PLC, weil sie SPS haben oder sowas. PLC ist übrigens das englische Wort von SPS. Hier haben wir den Web-Server auf der SPS. Wir suchen uns auch anzumelden. Ein Web-Server auf der SPS, um sich hier zu stellen, dass die SPS funktioniert und können auch das Passwort, die da kann, das verraten. Irgendwann werden wir uns angemeldet haben und dann sehen wir die ganze Funktionalität aus der linken Seite. Es funktioniert eine ganz normale SPS. Und jetzt werden wir das, die Firmware, die wir von Siemens heruntergeladen haben, entpacken. Wir wollen sicherstellen, dass die Leute aus dem Iran und Nordkorea es nicht bekommen. Also, ich bin aus dem Iran zum Beispiel. Hier haben wir das Firmware, die entpackt ist, aber weil es relativ groß ist, was wir jetzt 6 machen, ist 256 Kilobytes von der Firmware. Es wird hier nirgendwo... von der Firmware schauen wir uns mal in IDA an. Wir haben hier keine Funktionen. Dann exportieren wir ein Teil davon. Wir sorgen dafür, dass die Uhr etwas langsamer ist um sich hier zu stellen, dass es nicht zu schnell passiert. Also, dass der Uhr nicht voll wird, dass er nicht ein paar Folgen voll wird. Wir exportieren das relativ langsam, das ist vom Siemens Framework. Wir exportieren jetzt die Datendach aus. Das ist jetzt dieser Datei. In diesem Teil sind wir jetzt fertig. Wir werden dieselben Adressbereich in der SPS auslesen. Aus der funktionierenden, normalen SPS. Der oberen Teil ist das rohe Uhrart und unten ist der Kseil, den wir benutzen. Und wir setzen die SPS zurück und bevor es den Arbeitsspeichel überschreibt, lesen wir den Arbeitsspeichelbereich aus. Das ist dieser Adresse. Wir lesen es 156 KB und hier senden wir den Befehl. Wir senden Pakete und dann können wir den Payload. Das ist ja Herr TwinTump. Das ist aus dem Arbeitsspeichel der SPS. Das ist nicht mehr von der SPS. Wir kopieren das auf unsere Maschinen und dann vergleichen wir das. Dann haben wir den Speicher und dann vergleichen wir die mal miteinander und die Stimmen zu 100% überein. Das ist genau die Firma, die wir auch von der Siemens 5 haben. Wir kriegen sie direkt aus der Arbeitsspeichel der Siemens. Also, nächstes Beispiel. Wir können beliebigen Grund ausführen, sehr einfach und weiße. Wir schreiben ein kleines Software für die SPS und kriegen Antwort. Wir bitten die SPS uns eine Nachricht zu senden jedes Mal. Wir senden unsere eigene Software und die SPS senden uns das einfach zurück. Wir wissen, dass alles nur wie das für 4.2.1 ist. Weil ich glaube, Siemens hat den Bootloader in Dezember neu geupdatet. Das müssen wir jetzt anpassen. Und dass die SPS die das uns zu senden. Das sind Rohdaten, die SPS zu senden. Vielleicht ist das zu grundlegend. Das sind die Rohdaten, die wir von der SPS bekommen. Lass uns mal ein bisschen komplexeres stellen. Etwas, das nicht von uns ist. Lass uns ein Spiel spielen, Tic-Tac-Tau, innerhalb der SPS. Wenn ihr das nicht kennt, so funktioniert Tic-Tac-Tau. Ich bin gleich gut wie Google. Jetzt senden wir wieder unsere Software teilweise gut aus dem Internet. Komplieren das und laden uns auf die SPS hoch. Natürlich muss man viele Sachen abentasten, aber wir senden unsere Software. Das sind die Rohdaten vom Kleint. Im Endeffekt sieht man das Tic-Tac-Tau-Interface. Da müssen wir dann interagieren. Spieler 1 ist das X, Spieler 2 hat das 0. Ich hoffe, ich gewinne jetzt Spieler 1. Ja! Das war ein zweiter Demo. Auf viele weitere Ideen sind da auch, was wir anderen Code hinzufügen können. Wir arbeiten da immer noch dran. Viele andere Sachen von Siemens, sorry Siemens, wir arbeiten da dran, aber es wird noch weiteres geben. Aber in der Zwischenzeit gibt es noch Ideen für andere Leute, die auch anschauen wollen. Die Sicherheit von Siemens-SPSen analysieren. Mit dem Sonderzugriff kann man gewisse Sachen anschauen. Zum Beispiel kann man eine neue Firmware schreiben, ohne die ganze Kriptografische Überprüfung zu machen. Zum Beispiel kann man da mit ein Stückchen Software ausführen, bevor die Adonis Betriebssysteme komplett gebotet haben. Es gibt Webhändler mit Lilili und Lololon. Was man da auch machen kann, ist ein speziell zifischen Händler hinzufügen kann oder einen existierenden Händler überschreiben. Das kann man Tritone machen. Wir haben das in einer SPS und haben es in TCP gemacht. Wir warten einfach auf Befehle und andere Alternative wäre Software zu überschreiben, Jumptables zu überschreiben und Prozess auf spezifische Eingriffe durchzuführen. Was ist da immer noch? Was wir uns angeschaut haben, ist der Angriffsvektor von der SPS. Wir haben unterschiedliche Angriffsmethoden. Wir schauen uns immer noch Hardware und Software-Sachen an. Wir arbeiten immer noch dran. Die können wir jetzt auch nicht darüber reden. Was interessant ist, dass sich die Sicherheit von SPS interner sich anschauen möchte. Nicht nur dieses Netzwerk-Segmentierung. MWSL ist ein interessanter Angriffsvektor. Ich vermute, dass da noch ein paar Wachs sind. Und Firmware-Signing könnte auch problematisch sein. Der Echtzeitkompilierer ist auch ein bisschen problematisch. Wenn man sich remote anreicht, dann ist der Web-Server und der Netzwerkszugriff von Firmware und Firmware-Servers, die sie haben, potenziell interessant. Die schauen wir uns auch an. Jetzt abschließend. SPS werden komplexer. Es werden mehr Funktionen zur Verfügung stellen. Das heißt, es wird mehr Bugs geben. Zum Beispiel MWS, was wir uns noch nicht angeschaut haben. In diesem Web-Server. Außerdem versuchen die Hersteller komplexer zu machen. Sie haben die Bug-Funktionalitäten, die in den SPSen, aber auch Firmware-Integrationsverifikation. Wenn man sie auf die SPS hochlässt und sie versuchen ist, komplexer zu machen. Aber was sie auch wissen müssen, ist, dass in der Angriffsmodelle die Sicherheitsekosysteme, dass sie von ihnen erstellt wird. Wenn da eine Funktion ist, dass sie selber erstellt haben, was sie hier offensichtlich gemacht haben, mit den Sonderzugriff-Funktionalitäten im Bootloader, dann ist es problematisch. Das müssen dann auch die Kunden wissen. Solange Kunden wissen, worauf sie aufpassen müssen, dann ist es halbwegs in Ordnung. Aber ansonsten können sie sich selber nicht davor schützen. Außerdem müssen sie auch über Sicherheit, über Gegenobskurität überdenken. Vielleicht sollten sie uns als Forscher ein einfacher Zugriff geben. Wir schauen uns sowieso an. Vielleicht können sie es auch einfacher machen. Es kann auch viel mehr gemacht werden mit SPSen. Siemens wird nicht die letzte sein, die wir uns anschauen. Wir müssen auch noch einige Leute denken, z.B. Thorsten Holz, der jetzt nicht hier ist, von der Universität Trump, Thomas, Alexander, Maria, Lucian und die anderen, die auf der Folie sind. Und jetzt werden wir noch ein paar Fragen beantworten. Das war die deutsche Übersetzung des Talks Unbeschränkte Kotausführung auf Siemens S7 SPSen vom 36. KAUS-Communication-Kongress. Eure Übersetzer waren Franz T. und Tribut. Wir freuen uns über Feedback entweder per Mail an Hello at C3lingoorg oder auf Twitter mit dem Hashtag C3T. Ich habe eine Frage aus dem Internet. Habt ihr den MC7-Paser euch näher angeschaut? Habt ihr da unbekannte Instruktionen, die dort verwendet werden? Ja, Tobi, möchtest du da antworten? Nee? Also ist das aufgenommen oder muss ich das wiederholen? Also, okay. Ich muss es nicht wiederholen. Also haben wir nicht gemacht. Wir haben uns das nicht genauer angeschaut, aber wir arbeiten da jetzt dran. Wie konntet ihr das Passwort finden? Das ist eine relativ lange Geschichte. Wir hatten das schon lange vor uns, bis Siemens dieses Anti-Debugging-Feature eingeführt hat. Und dann mussten wir andere Wege finden, das rauszufinden, ähnliche Funktionen, ähnliche Varianten. Also, was wir hier nicht zeigen, ist, wie wir diese Instruktion ausgeführt haben. Da haben wir von einigen Forschern aus Holland Hilfe und aus Frankreich. Das waren also Dinge, wo Siemens 2013 bis 2016 davon wussten. Die haben das gepatched. Die hatten dann versucht, ihre SPS von dieser Attacke zu schützen. Das wurde nicht publiziert. Wir haben es benutzt, aber wir wollten es nicht darüber reden. Aber wir haben das repliziert, was die machen konnten. Und dann, nachdem wir dann also andere Wege suchen mussten, da hat uns das dann unsere Augen geöffnet, dass es da auch andere Funktionalitäten gibt, zum Beispiel in diesem Boot lauter. Bevor wir es gebraucht hatten, haben wir uns das nicht angeschaut. Es war in gewisser Weise vor uns für zwei Jahre lang. Also, eine Sache, eine Hintergrundgeschichte, die vielleicht ganz interessant ist, in der vorherigen Technik, die wir benutzt haben, wo wir den Sprungbefehl überschrieben haben, der zu diesem Spezialzugrifffeature, den haben wir mit einem unkonditionierten Sprung. Dann haben wir einfach 60 Prozent des Firmwareimages übersprungen. Und die Vermutung, dass da einfach zu viel Funktionalität drin war, die ich vorhin schon hatte, wo ich vorhin schon drüber gesprochen habe, und dann haben wir halt gezeigt haben, okay, das ist jetzt genau dieser Ort, den wir vorhin überschrieben hatten, und den haben wir dann für uns selbst benutzt. Gibt es irgendwelche Bootsicherheit außerhalb des CRCs? Überprüfungen könnte man den Inhalt des SPI Flash überschreiben und beliebige Kurtersführer durch erlangen. Also, es hängt davon ab. Je nachdem, in welchem Jahr, also 2017, 2016, es geht immer um das selbe Modell der SPS, 2019, nein, da, 17, 18, nein, da konnte man einfach den kompletten SPI Flash überschreiben und das war in Ordnung. Aber wenn das ein Hold ausführt, dann würde das, diese Anti-Debugging Funktion dieser Watchdog würde davon ausgeführt, getriggert werden. Aber was Frameware, die wird auf den Nand geschrieben und dann ist es nur eine CRC Summe. Während des Updates gibt es einige kryptografische Checks, aber bei der Ausführung nicht. Es gibt da noch einige Probleme, das ist noch Forschungsgebiet, da wollen wir noch nicht darüber reden, aber, ja. Könnt ihr mehr darüber reden, wie ihr mit dem Hersteller geredet habt und eure Zeit schien? Wir hatten das Problem anderthalb Jahre schon gekannt, bevor wir uns mit dem Hersteller in Verbindung gesetzt haben. Das liegt auch daran, dass wir das für andere Projekte benutzt haben. Das war eigentlich ein Seitenprojekt gewesen. Das Hauptprojekt, das arbeiten wir noch dran, das läuft noch. Aber von diesem Seitenprojekt hatten wir diesen Zugriff und wir hatten Angst, dass der Hersteller das dann ändert und dann die anderen Sicherheitsprobleme, die wir von dem anderen Problem noch finden könnten, dass die dann nicht zugelassen worden würden. Und Thomas wollte über sein Talk nicht sprechen, dieses J-Tech-Interface für CoreSight. Und dann haben wir beschlossen, okay, jetzt reden wir auch drüber. Aber ansonsten haben wir im Juni mit Siemens gesprochen und die haben bestätigt, dass es dieses Hardware-Spezialzugriffsfeature gibt und die haben gesagt, sie werden das entfernen. Und das war es im Wesentlichen. Wir haben auch einen Aufschrieb Ihnen geschickt. Auch eine Frage aus dem Internet. Wie kann man das auslesen, kann man Firmware auslesen, wenn der Standard Firmware auslesen Werkzeug für Linux, wie zum Beispiel Flashroom, das nicht auslesen kann. Also, wenn Flashroom das nicht auslesen kann, das Werkzeug, wie kriegen wir dann die Firmware, wenn wir nicht die... Also, wir haben den Flashchip, haben wir nie decapt, also da haben wir nie die Hülle abgemacht. Wir wussten ja, dass Siemens hat keine eigene CPU gehabt, deswegen haben wir das abgemacht. Aber von anderen Sachen, diese Funktionalität, diese Bootloader-Funktionalität, die einem erlaubt, den Speicherinhalt zu lesen, das braucht man ja am Ende nicht. Dank einer meiner Studenten hat da herausgefunden, dass man den Bootloader-Chip nicht mal rausnehmen muss. Man kann direkt auf die Platine verbinden und die Firmware dampen. Und Marcelo hat das herausgefunden, der ist auch hier. Und man kann das direkt lesen. Und ich denke, dass lesen, also manche Teile sind geschützt, vor allem in den neueren Versionen, man kann nicht alles lesen, aber davon mal abgesehen sehe ich nicht, dass es Hardware-Schutz gibt, aber ich bin sicher, dass Sie daran arbeiten und wir arbeiten auch an Varianten, um das zu umgehen. Tschüss.