 Imagine you're running a PLC in your industry application and some attacker comes out. Ja und dann begrüßen wir euch auch schon mal ganz herzlich aus der Übersetzungskabine. Wir sind FLOX und Tribut. Wir übersetzen heute den Vortrag. Tu was ich dir sage, nicht dass ich selber tue. Heimliche Manipulation der einen Ausgabe von Speicherprogrammierbaren Steuerungen durch Manipulation der PINs. Und dazu begrüßen wir bitte ganz herzlich die beiden Sprecher Ali Abasi und Majid. Danke. Hallo zusammen. Herzlich willkommen zu unserem Talk. Es geht um die Manipulation der einen Ausgabe von Speicherprogrammiergebischen Steuerungen durch Manipulation der PINs. Ich bin ein Doktorant an der Universität in Trient und bin auch in Bochum aktuell zu Gast als Forscher. Und ich bin Majid und ich habe Informatik studiert und habe meinen Masterabschluss in künstlicher Intelligenz. Und ich kümmer mich auch um Systemsicherheit von Speicherprogrammierbaren Steuerungen. Und als ich hierher kam, habe ich dieses Bild gesehen, also wo es darum ging, wählt eure Seite und er wählt Club Marte. Also, wir fangen an mit Hintergrund um Prozesssteuerung und auch weiteren Hintergrund über schon existierende Steuerungen auf SPS. Und das ist wichtig für unseren Angriff, denn wir sehen dann, warum wir unseren Angriff machen. Und dann macht es Sinn, wenn ihr seht, welche Verteidigungsstrategien es auch gibt. Und wir wollen uns auch anschauen, welche von diesen Verteidigungsstrategien auch allgemein auf Speicherprogrammierbare Steuerungen angewandt werden können. Und dann kommt der zentrale Part, der Hintergrund auf Manipulationen der PINs, was die Probleme hier sind. Und dann gibt es eine Rootkit-Variante unseres Angriffs und welche, wo man keinen Rootkit installiert. Und dann zeigen wir euch Demos und am Ende reden wir nochmal drüber mit euch. Worum geht's? Also, bevor wir anfangen, es gab eine ganze Menge Medienhype über unsere Arbeit und deswegen will ich kurz sagen, worum es bei uns eigentlich geht. Also, wir wollen zeigen, dass speicherprogrammierbare Steuerungen gewisse Designprobleme haben und die können von zukünftigen Angreifern benutzt werden. Und es geht also hier nicht um eine neue Generation von Stuxnet. Also, es wird jetzt keine vollständig funktionierenden Rootkits geben von uns. Also, die kann man dann nicht einfach irgendwo ausführen und die wird auf jeden Fall funktionieren, unabhängig von der Architektur und dem Betriebssystem. Und es geht auch nicht um Exploits im Allgemeinen, sondern also, wir werden auch keine Herstellername nennen. Also, keine Namen und wir werden auch niemanden beschämen. Also, zuerst mal, wie sieht so ein industrielles Kontrollsystem aus? Ganz allgemein bestehen die aus drei Teilen. Das erste ist die IT-Technologie, also das ist Active Directory, Mail Server, Dateiserver. Und in diesem Teil des Netzwerks sind die Rechner der Benutzer. Das, wo die Leute im Internet surfen oder Dateien ausführen. Und der nächste Teil ist Operational Technology, also da sind die speicherprogramierbaren Steuerungen und dann gibt es den Physical Application Layer, also die physische Geschichte, also die physischen Teile des Netzwerks, also die Sensoren, die Ports und so weiter. Und es ist ganz interessant zu wissen, dass dieses Ding hier überwacht wird und kontrolliert wird von dem operationalen Teil, den wir vorhin erwähnt haben. Und ein Angreifer, der versucht so ein Netzwerk anzugreifen, da könnte das letztendliche Ziel sein, Schaden in der physischen Anwendung zu verursachen. Also, um das besser zu verstehen, ist es wichtig zu verstehen, wie Prozesskontrolle funktioniert. Und eines der einfachsten Beispiele ist zum Beispiel ein Thermostat. Also, früher, wenn ihr eure Temperatur im Raum erhöhen wolltet, dann musstet ihr das manuell machen. Aber heutzutage könnt ihr ein Thermostat so konfigurieren, dass er auf eure Lieblingstemperatur konfiguriert ist und er ändert dann die Temperatur dynamisch. Und die Kontrolle funktioniert, indem ihr einen Sensor ausliest und der geht dann in das Kontrollsystem, der Wert. Und in diesem Teil macht der Thermostat Entscheidungen, was er jetzt machen soll, also, ob er die Temperatur erhöhen soll oder reduzieren soll. Und das Ergebnis geht dann als Kommando, als physikalischer Prozess zu dem Heizsystem und diese Schleife, die wird immer wieder durchlaufen. Und in einem, wenn man eine große Anlage sich anschaut, dann ist es natürlich viel komplizierter als einfach nur in einem Thermostat. Und deswegen brauchen wir eine Speicherprogrammierbildersteuerung, eine SPS oder PLC im Englischen. Und das sind Hauptkomponenten von jedem industriellen Netzwerk. Und das sind eigentlich nur Embedded-Geräte, die ein Echtzeitbetriebssystem, auf denen auf Echtzeitbetriebssystem läuft und die enthalten Logik. Und das ist einfach nur ein Programm, was diese Steuerung ausführt. Und dadurch werden die Regeln definiert, was die Speicherprogrammierbare Steuerung tun soll oder nicht tun soll. Und wenn wir uns zum Beispiel hier so eine Logik angucken, wenn der Input von dem Eingabekanal 1 größer ist als ein bestimmter Wert, dann wird er den Output an einem anderen Port ändern. Also schauen wir mal an, was eine speicherprogrammierbare Steuerung mit Logik tun kann. Wir haben jetzt einen Drucksensor und die Logik innerhalb der Steuerung liest dann den Wert vom Sensor und macht eine Entscheidung basierend auf dieser Eingabe und wird dann entsprechend dazu eine Ausgabe erzeugen. Aber kleine Änderungen in der Temperatur des Raums kann kein Problem sein, aber es kann eine echte Bedrohung sein in so einem Netzwerk. Und deswegen benutzen wir Kontrollalgorithmen. Und die Idee ist, das Risiko von bestimmten Operationen zu bestimmen. Also wenn man definiert haben will, dass die Temperatur nicht höher sein darf als 20 und wenn wir in dem letzten Durchlaufen 19 gesehen haben, dann werden wir ausrechnen, was jetzt passiert, wenn dieser Loop noch einmal durchläuft. Und die Frage ist, sollen wir den Prozess jetzt anhalten oder ist es nicht wirklich gefährlich? Das heißt, wir können es einfach noch mal durchlaufen lassen. Okay, also jetzt, wo wir ein grundsätzliches Verständnis haben, werde ich euch eine kurze Einführung geben in Angriffe und Verteidigungen. Eine der einfachsten Angriffe gegen PLCs ist die Authentifizierung zum Gehen. Das heißt, man kann sehr einfach zum Beispiel das Standardpasswort ändern, aber es ist sehr... Man kann sehr einfach die Standardpasswörter rausfinden. Die sind fast bei allen Geräten ähnlich, das ist bei allen ähnlich. Man kann auch eine modifizierte Firma hochladen. So kann man dann die Logik in dem Gerät modifizieren und die veränderte Logik hochladen. Dann kann man Bufferoverflows ausnutzen und die andere Möglichkeit ist ICS Malware zu nutzen und die Malware wird die eigentliche Software angreifen, indem man sie Hux installiert und die man nutzen kann. Aber die... Und womit kann man sich jetzt schützen? Eine Möglichkeit ist, wir wollen sicherstellen, dass der Speicher den bestimmten Zustand tatsächlich auch abbildet. Dann gibt es auch Firmware-Integritätsprüfung. Das heißt, wir können prüfen, dass... Bevor wir die Firmware installieren, neue Firmware installieren, prüfen wir, ob das System... Also, ob die Firmware tatsächlich auch von einer vertrauenswürdigen Quelle gestand. Und dann gibt es auch noch weiter, also detailliertere Schutzmechanismen. Also zum Beispiel, indem man die Hux und die Daten ein- und ausgabegenauert prüft. Und nicht alle von diesen Verteidigungsmechanismen kann man auch auf speicherprogrammierbare Steuerungen anwenden. Also manche benötigen Veränderungen der Hardware. Und nachdem wir nur sehr wenig Ressourcen haben auf so einem System, sollte es nicht zusätzliche Arbeit machen für das Gerät. Denn fast alle der schon hergestellten speicherprogrammierbaren Steuerungen unterstützen keine Virtualisierung. Das heißt, es ist sehr unwahrscheinlich, dass wir in Zukunft Virtualisierungsunterstützung haben in den PLCs. Das heißt, alle Schutzmechanismen, die Virtualisierung brauchen, können wir nicht benutzen. Und jetzt machen wir zwei Kategorien für die Schutzmechanismen. Die erste sind Logik, Chexsomen und Firmwareprüfung. Das sind einfach ganz triviale Schutzmechanismen. Und die andere Kategorie ist Doppelgänger. Hier geht es Doppelgänger und Autoscopy sind einfach zwei in dieser Kategorie. Und wie funktioniert dieses Doppelgänger? Der benutzt tatsächlich eine Zusicherungslösung, also eine Attestationlösung. Die benutzt die Scant ein Firmware-Image und sucht dann nach ausführbarem Code und installiert dazu zufällig ein paar Watch Dogs. Das heißt, jedes Mal, wo einer dieser Watch Dogs ausführt, wird er prüfen, ob die Speicherregionen, also die Chexsomen einer Speicherregion sich nicht verändert hat. Und wenn das so der Fall ist, dann ist alles gut. Und dann gibt es AutoscopyJR. Das ist ein Schutz für, wenn der Ablauf des Programms sich ändert. In der ersten Phase lernt das System gewisse Informationen über den Ablauf. Also die Adresse der Funktionen und Parameter und die Rücksprungadresse. Und speichert das in einer vertrauenswürdigen Tabelle. Und später, wenn das Programm läuft, werden dann die Informationen zur Laufzeit verglichen gegen diese statische Lift-Liste. Und wenn die Werte übereinstimmen, dann sagt das System, alles ist in Ordnung. Also diese zwei Lösungen versuchen, gegen Hooking und Manipulation von Daten zu schützen. Aber nicht alle Good-Kids funktionieren durch Manipulation von Code oder Speicher. Also zum Beispiel kann man auch einfach bestimmte... Hier zum Beispiel, hier gibt es ein Frag-Magazin, wurde vor langer Zeit dokumentiert, in dem man... Also das könnt ihr euch nachher anschauen, wenn euch das wirklich interessiert. Und jetzt gehen wir aber weiter auf die Pinsteuerung und auch die Attacke, die wir durchgeführt haben. Also ihr fragt euch vielleicht, warum haben wir jetzt so einen Haufen Hintergrund über aktive Verteidigung für die PLC's erwähnt haben. Und es macht jetzt mehr Sinn, uns die Attacke anzusehen unter der Bedingung, dass wir aktive Verteidigung im PLC haben. Und die ersten PLC's mit aktive Verteidigung werden vielleicht schon 2020 oder ein bisschen frühen. Also es gibt zwei verschiedene Art und Weisen, wie wir Pin angucken können. Eine ist Multiplexing, das heißt, wir haben zwei verschiedene Pins und ich rede jetzt tatsächlich von echten Pins, die man sich angucken kann und anfassen kann. Und die zwei haben zwei verschiedene Funktionen. Und ich kann entweder nur die eine oder die andere Funktion benutzen. Und das liegt daran, dass der Chip-Entwickler vielleicht verschiedene Funktionen für den Chip vorsieht. Also es gibt eine Funktion, zum Beispiel für einen Hersteller von Mobiltelefononen und eine anderen Kunden auf dieselbe Platine. Und je nachdem, welche Firma diesen Chip dann nutzt, die kann dann... Also wir können einen Chip herstellen und verschiedene Firmen können das für ihr Ding benutzen. Und das nennt man dann Pin-Multiplexing. Das macht also Chip-Design ein. Und was wir jetzt sehen, wenn man Kontrolle über die Pins hat, ist Pin-Konfiguration. Also wir konfigurieren die Pins tatsächlich, indem wir zum Beispiel einstellen, ist das Eingabe oder Ausgabe. Das heißt, es gibt ganz allgemeine Regeln, die diese Pins betreffen. Und das müsst ihr euch jetzt merken, bevor wir weitergehen. Denn bei einem Input-Pin, also bei einem Pin über den Eingabe passiert, wo man zum Beispiel Werte einlässt, kann man den nur benutzen als nur Lesepin. Also man kann also niemals Daten schreiben auf einen Pin, der als Input beschrieben wird. Das ist eine ganz allgemeine Regel. Und wenn es eine Ausgabepin ist, das heißt, wir steuern darüber Geräte, dann können wir lesen, also wir können davon Daten lesen und wir können Daten dahin schreiben. Also ihr könnt beide Sachen damit machen, wenn es ein Output-Pin ist, ganz allgemein. Also wenn wir uns hier eine Beispiellogik angucken, hier Pin24 ist ein Input-Pin und Pin22 ist ein Output-Pin. Und wenn ihr da unten seht, ja auch nochmal dasselbe, da gibt es die Konfiguration dazu. So, jetzt müssen wir wissen, wie die PLC mit diesen Pins interagiert. Bevor ich anfange, möchte ich noch mal erwähnen, ich habe es schon mal gesagt, aber es gibt eine Hauptapplikation, also die Laufzeit, das wird normalerweise nicht geändert, außer wenn man die Firmen wer updated. Und es gibt einen anderen Teil, in die die Operators in einem Kraftwerk zum Beispiel programmieren und deswegen heißt eine Speicherprogrammierbare Steuerung programmierbar und das zum Beispiel beschreibt dann, wenn die Temperatur das Eingangsblah mehr als irgendwas ist, dann macht das und das ist diese Logik. Und was die Laufzeit macht, es kann auch ein Treiber sein, ist, dass diese Adressen irgendwie da reingemäppt werden. Aber jetzt schauen wir uns das einfach mal an auf einem Beispiel. Warum ist das jetzt ein Problem? Das Problem nennen wir Memory Illusion, also die Illusionen von Speicher. Und wir haben ein Betriebssystem, es gibt physikalischen Speicher und was passiert ist, dass die Laufzeit- umgebung von der Speicherprogrammierbaren Steuerung einen Ausgabespeicher anfordert. Das wird dann benutzt, um dieses Gerät zu kontrollieren und sagt dann den Betriebssystem hier, meppe mal diesen Speicher hier in meinen Ausgabespeicher. Und dann gibt es den Operator, also den Mitarbeiter im Kraftwerk und der sagt dann, ich möchte, dass das Ding das und das macht und das wird jetzt auf die PLC hochgeladen und wie gesagt, das nennen wir die Logik. Also in diesem Beispiel zum Beispiel haben wir eine Logik, die sagt, wenn PIN 24 wahr ist, dann soll alle fünf Sekunden auf der PIN 22 an und ausgeschaltet werden. Also wir sehen in dem Beispiel sofort, dass PIN 24 ein Input PIN ist, denn wir schauen einfach die ganze Zeit, ob es wahr ist und wir updaten PIN 22. Also wir ändern PIN 22, das heißt, es ist ein Output PIN. Und was jetzt passiert ist, dass diese SPS, den Zustand ändert in einem Zustandsregister, das nennen wir Zustandsregister. Also wir sagen zum Beispiel, PIN 24 ist eine Eingabe, dann gibt es hier einen Zustand und PIN 22 ist Output, ist in dem Fall 0 für Eingabe, 1 für Ausgabe. Und dieser Wert dann wird in das physikalischen Speicher gesendet und aufgrund unserer Logik lesen wir jetzt also den Wert von PIN 24. Wenn PIN 24 wahr ist, dann können wir weitermachen mit PIN 22. Also wir lesen das aus diesem virtuellen Speicher, aber in Wirklichkeit kommt es vom physikalischen Speicher. Und dann alle fünf Sekunden, sagt die PLC dann, ich möchte 0 oder 1 in den virtuellen Speicher schreiben und das bedeutet dann, ich schalte irgendwas an und aus, also zum Beispiel eine LED, alle fünf Sekunden. Das ist also zum Beispiel was, was alle fünf Sekunden passiert und das wird dann, je nachdem was gegelesen wird, immer wieder passieren. Und was ist jetzt das Problem? Was wäre denn, wenn wir, also wir nehmen folgendes an, ein Angreifer, der ohne dass die Speicherprogrammierestörung das weiß, also ich meine, die weiß es natürlich nie, ist, hey, ich habe hier eine neue Konfiguration für den PIN 24, die ich jetzt benutze. Und was der jetzt macht, das ändert den Zustand von PIN 24 von einer Ausgabepin zu einem Eingabepin. Es war vorhin Ausgabepin, wir schreiben ja alle fünf Sekunden hin. Aber ich sage jetzt in einem anderen Register, hey, PIN 22 ist ab jetzt nur noch Eingabe. Und das wird dann also in das virtuellen Speicher geschrieben und am Ende auch in den physikalischen Speicher. Und was wir jetzt haben, das ist ganz interessant, denn die Laufzeit der SPS nimmt jetzt immer noch an, ich muss alle fünf Sekunden die LED an- und ausschalten. Das heißt, es versucht dann, 0 oder 1 in das rechte Register reinzuschreiben, an- und ausschalten. Aber was jetzt passiert ist, und das ist das zentrale Problem, ihr könnt da einfach nicht mehr hinschreiben, das ist nicht möglich. Die allgemeine Regel, die ihr euch hoffentlich gemerkt habt, ist, ein Eingabepin kann nicht beschrieben werden. Und das Problem ist, dass die CPU oder der System on the chip, die geben dir kein Feedback. Also hey, du kannst da gar nicht hinschreiben, sondern alles sieht gut aus. Und das nennen wir eine PIN-Konfigurationsattacke. Also wir können die Konfiguration ändern, wie das genau geht, da reden wir nachher drüber. Und jetzt ändern wir das einfach mal. Also wir haben noch ein zweites Register, das nennen wir das, also das Multiplexing-Register. Ich habe jetzt einfach mal da den Namen von diesem Zustandsregister in das Multiplexing-Register umbenannt. Und jetzt sage ich einfach mal, hier PIN 20, sagen wir mal, das war angeschlossen an einem Motor. Also es ist kein GPIO-Port, sondern SCI oder irgendwas Ähnliches. Und jetzt ändern wir das. Es ist also jetzt nicht mehr eine Logik, dass LED an und ausgeschaltet wird, sondern es ist ein Motor zum Beispiel. Und was ich als Angreifer jetzt mache, ist, ich sage hey, multiplexe mal den PIN 22 von diesem PIN auf einen GPIO-Pin oder irgendwas anderes. Und was jetzt passiert ist, also diese Werte, die sind eigentlich gar nicht wichtig. Aber alle fünf Sekunden versucht jetzt die Laufzeit von der SPS hier drauf zu schreiben, aber es kann nicht schreiben, denn nun ja, wir haben ja den Anschluss physikalisch ausgeschaltet, dadurch, dass wir den PIN multiplex haben, der vorher benutzt wurde. Und das ist ein Problem, denn schauen wir uns mal ein Beispiel an, wie ein USB-Stick in Windows. Ihr kopiert eure Dateien und plötzlich nehmt ihr den USB-Stick raus. Was wird passieren? Okay, es gibt ein Fehler. Boom, dieses Device ist nicht mehr verfügbar, deswegen können wir es jetzt nicht kopieren. Und was jetzt passiert ist, wenn wir PIN-Multiplexing machen speziell, ist, der eine Ausgabe ist nicht mehr verfügbar, aber der virtuelle Speicher ist noch da. Das heißt, das Betriebssystem redet immer noch mit dem virtuellen Speicher, aber es kann nicht auf den Hardware, also den eigentlichen USB-Stick kopiert werden. Aber es gibt keinen Feedback, das heißt, das Betriebssystem sagt nicht Bescheid, hey, diese eine Ausgabe ist nicht mehr verfügbar. Also, wir zeigen euch jetzt eine kurze Demo, wie das funktioniert. Das ist uns am Anfang zu anfangen. So, hier haben wir zum Beispiel ein Beispielprozess. Und das sagt zum Beispiel, liegt PIN 22 als Eingabe fest und PIN 22 als Ausgabe. Und alle fünf Sekunden will ich die LED, die zu PIN 23 verbunden ist, an und auf ausschalten. Das sieht man jetzt hier. Die LED geht an und aus. Wir benutzen hier jetzt eine echte PLC-Roundtime, die auch in kommerziellen Systemen benutzt wird. Wie ihr seht, wird der Wert falsch und die LED ist aus. Wenn der Wert auf wahr steht, ist die LED an. Und wenn der Wert wieder auf falsch steht, ist die LED wieder aus. So, wir werden jetzt die PIN-Konfiguration manipulieren. Zum Beispiel, wenn der PIN ein Output-Pin ist, ändern wir den zu einem Input-Pin. Wir zeigen jetzt, dass es da auch keinen IO-Fehler, es gibt keinen Fehler im Kernel. Es gibt keinen Fehler in irgendeiner Weise. Es sieht alles sieht gut aus. Und das ist wichtig. Wir haben hier keine Hux, keine Funktionen eingehuckt, eingehängt. So, hier sieht man, die LED geht immer noch an und aus. Und was wir jetzt machen, im Moment blockieren wir nur die Funktion. Und immer wenn wir versuchen, auf eine Open zu schreiben, ändern wir den Status des Ios von Output zu Input. Es ist jetzt ein Read-Only, also nur lese PIN, und wir können nicht mehr auf den PIN schreiben. Und die PLC Runtime denkt, alles ist gut. Und nichts passiert. In der nächsten Demo... Verzeihung. Und jetzt zeigen wir euch nur, dass wir hier die korrekte Funktion der Runtime abfangen. Und schreiben auf den IO. Und jetzt sieht man hier, die LED blinkt nicht mehr, aber die PLC Runtime weiß nichts davon. Und wir schalten jetzt um auf die Programmierstation. Und die PLC zeigt immer noch fünf Sekunden lang wahr und fünf Sekunden lang Falls für den LED-Bind. Aber die LED geht nicht mehr an. Weil wir den Status des Output Pins immer ändern, wenn die PLC versucht, darauf zu schreiben. Also, das ist ein Problem, das wir... Und das ist ein Problem, wo man am Anfang gedacht hätte, das müsste auffallen und es müsste irgendeinen Fehler geben, wenn der IO-Termin nicht mehr verfügbar ist. Und das ursprüngliche Problem ist, dass es keinen Interrupt dafür, wenn sich die PIN-Konfiguration ändert. Und dadurch weiß die PLC nicht, dass sich die PIN-Konfiguration oder das Multiplexing-Feature geändert hat. Und wenn es einen Fehler, wenn es einen Feedback gebe, dann... Ich weiß nicht, ob es die Möglichkeit ist, einen Interrupt dafür zu schalten, weil das sehr teuer ist. Also, wir haben uns entschieden, einen Angriff zu schreiben. Und wir sind dabei davon ausgegangen, dass es diese aktiven Verteidigungen gibt für PLCs. Und wir... das heißt, wir wollten keinen Funktion-Hooking benutzen, weil wir davon ausgegangen sind, dass es eben aktive Verteidigung für PLCs gibt, die da nach ausschalhalten. Und natürlich wollen wir den ausführbaren Inhalt des PLCs modifizieren und wir gehen davon aus, dass es gibt Logikchecksams und das heißt, wir gehen davon aus, dass eine Modifikation der Logik detektiert werden kann. Und jetzt... hier kommt der PIN-Kontroll-Angriff und wir nennen es PIN-Konfiguration-Angriff. Also entweder wir machen so einen Konfiguration-Angriff oder wir machen eben so einen Multiplexing, das heißt, wir ändern die Multiplexing-Konfiguration von so einem einzelnen PIN. Und wir haben da also zwei Varianten implementiert. Das erste ist so ein Routkit. Da brauchen wir also Routrechte dafür und ein gewisses Wissen über die System-on-Chip-Register und auch ein gewisses Wissen über das Mapping zwischen den einen Ausgabepins und eine zweite Variante ohne Routrechte. Also, wie funktioniert das jetzt? Nehmen wir mal an, wir wollen die Laufzeit... wir wollen, dass die Laufzeit auf einem bestimmten PIN schreibt und wir wollen diesen Wert manipulieren, den da hingeschrieben wird. Und was wir machen ist, wir benutzen die Debug-Register und wir benutzen die virtuell gemappten Einausgabe und da versucht dann die Laufzeit hinzuschreiben, aber wir haben das quasi schon in den Debugger gesetzt, sodass wir die richtige Operation abfangen können. Und wir leiten die jetzt nicht einfach um, sondern was wir machen ist, wir gehen jetzt in ein anderes Register, ein Zustandsregister und ändern die Konfiguration des PINs. Wir wissen, dass die PLC da versucht hinzuschreiben. Und wir ändern das auf Input und das bedeutet natürlich, dass das nicht funktionieren wird, denn wir können ja nicht auf eine Eingabepin schreiben. Und was wir jetzt machen können, ist, wir können das wieder in den Debug-Modus schalten und dann versucht die PLC davon zu lesen und wir fangen das ab und wir ändern jetzt den PIN wieder von Input auf Output, das ist also genau umgekehrt. Und dann schreiben wir den Wert, den wir sehen wollen. Also wenn wir zum Beispiel einen Temperaturwert sehen wollen, dann setze ich den einfach mal auf, also dann setze ich den auf den Wert, den ich dann, der ich will, das eingelesen wird. Und dann sorg ich dafür, dass es weitergeht. Und was passiert ist, also ihr les den Wert, den ich euch vormachen will und nicht der, der tatsächlich an dem Sensor anlegt. Und was wir jetzt machen ist, wir schauen euch erstmal noch mal eine Demo. Und was wir haben ist, also dieselbe Logik, von der wir gerade gesprochen haben, also zum Beispiel alle vier Sekunden, wird eine LED an- und ausgeschaltet. Aber dieses Mal wollen wir die Attacke durchführen. Das heißt, wir wollen sehen, was tatsächlich passiert. Also es geht nicht nur darum, das zu blockieren, dass es nicht mehr passiert, sondern wir wollen es tatsächlich manipulieren, genauso wie ich es vorhin auf der letzten Folie beschrieben habe. Wir haben eine LED, die ist an dem PIN angeschlossen und die wollen wir an- und ausschalten. Alle vier Sekunden zum Beispiel. Aber der Angreifer will vielleicht nicht alle vier Sekunden, sondern er will das vielleicht jede Sekunde machen. Und also das war die Logik, die wir jetzt auch für die nächste Demo benutzen. Und dann gibt es noch ein paar Leute, die gesagt haben, naja, also was ihr implementiert habt, das hatte nichts mit einer echten SPS zu tun, weil das waren ja im Prinzip nur zwei Register, die ihr durch die Laufzeit von einer PLC. Und bei einer echten PLC ist das vielleicht anders. Und was wir jetzt also implementiert haben, ist, dass auch einfach in einer PLC, wie bei einer echten PLC, die Logik wie in einer echten PLC, das kann man jetzt nicht so richtig sehen, kluge Leute werden das rausfinden. Das ist der Test, den wir haben, wir schauen euch gleich ein Video. Und das war die zweite SPS. Ja, also tweetet vielleicht den Herstellernamen, wenn ihr das Geräte erkannt habt. Und was wir jetzt machen ist, wir ändern den physikalischen Prozess, ohne dass die Laufzeit der speicherprogrammierten Steuerung das mitbekommt. Was wir haben ist, alle vier Sekunden geht die LED an und aus. Also ihr seht hier oben immer true, also war und dann geht die LED an und false, also falsch, und dann geht die LED aus. Und dann führen wir unsere Attacke aus und wir ändern jetzt tatsächlich den Prozess. Also was passiert ist, die Laufzeit scheint immer noch anzunehmen, dass vier Sekunden oder fünf Sekunden lang wahr oder falsch ist, aber der physikalische Prozess ist tatsächlich nicht genau so. Und wenn wir uns überlegen, der Mitarbeiter in einem Atomkraftwerk sieht jetzt quasi gar nicht, was passiert. Und jetzt machen wir es mit einer echten SPS. Also wir haben die Namen hier überklebt von dem Hersteller. Und was wir machen ist, wir schalten also wieder die LED an und aus. Also ihr könnt das hier sehen, alle zwei, drei Sekunden ändert sich das. Wir haben auch hier einen Aufkleber drüberkleben müssen. Also ihr könnt es sehen, die LED geht an und aus, sondern machen wir die Attacke an. Und diese Implementierung ist jetzt ein bekannter Roadkit. Also wir benutzen hier jetzt also keinen ... Ach so, das ist die Nicht-Roadkit-Variante. Also wir benutzen hier keinen Kernelzugriff. Danke André, falls du hier gerade zuschaust, er hat das Video gemacht. Also es braucht ein paar Sekunden, bevor die Attacke wirksam wird. Also was wir zum Beispiel machen wollen, die LED soll ausgehen. Ohne dass die Laufzeit-Umgebung der PLC das bemerkt. Und was ich also beschlossen habe ist, die LED muss anhalten. Und ihr seht es, also jetzt habe ich mich um entschieden, jetzt darf sie wieder blinken. Und jetzt entscheide ich mich, nein, stopp, aber der Wert ist oben bar. Aber die LED ist nicht tatsächlich an. Das heißt jedes Mal, wenn ich so eine Entscheidung treffe, die LED anzuhalten, was sie ... oder davon abzuhalten zu tun, was sie tun soll, ohne dass das Betriebssystem oder die Applikation davon weiß. Ja, also so funktioniert das. Jetzt muss ich leider kurz was trinken. Und es gibt hier wie jetzt kein Input-Output-Fehler. Ein Ausgabefehler. Wenn wir entscheiden, dass die LED ausgehen soll, auch wenn die SPS denkt, sie ist an, dann ist sie aus. Und wenn wir das wollen, ist sie aus. Das Problem ist, was der Operator in der Anlage sieht, ist komplett verschieden von dem, was tatsächlich passiert. Und das ist ein Problem. Und das ist das Kernproblem. Der Operator sieht was anderes, als der physikalische Prozess tatsächlich macht. Und ich hatte gestern eine andere Präsentation über die Sicherheit von ... darüber, wie gut sie im Bett ... die Sicherheit der im Bett etwas ist. Ja, und diese Binarys sind tatsächlich auch geschützt, aber nicht gegen statische Analyse oder auch dynamische Analyse nicht. Und einer der Hersteller, das hat uns tatsächlich überrascht, ist, dass tatsächlich mal das Binary geschützt war gegen statische Analyse. Und das war nur gepackt, also nur zusammengepackt. 99 Prozent der Datei waren gepackt. Und es waren tatsächlich nur ein paar einfache Funktionen, die diese Datei ausgepackt haben. Und der gleiche Hersteller hat einen einfachen Anti-Debugging-Trick benutzt. Das heißt, der Elternprozess hat sich an den Kinderprozess angehängt, was andere Debugger davon abhält, sich da anzuhängen. Und das ist also nicht neu. Da gibt es auch schon Informationen aus dem Internet, aber das hat uns tatsächlich überrascht, dass es das in der SPS-Welt auch gibt. Und wir wussten nach einer Weile, was für Informationen wir suchen. Also haben wir S-Trace benutzt. Und die einzige Herausforderung da war, wir hatten eine sehr eingeschränkte Menge von Ressourcen auf der SPS. Und S-Trace hat eine ganze Menge Ausgabe erzeugt. Die konnte die SPS nicht handhaben, die ist einfach deswegen abgestürzt. Und was wir deswegen gemacht haben, ist, wir haben S-Trace manipuliert. Das ist einfach nur die Information, also nur die Information sammelt, die wir brauchen. Und dann war es ganz einfach, diese Informationen auch rauszuholen. Und wenn ihr euch daran erinnert, diese zwei Schutzmechanismen, die ich am Anfang eingeführt habe, diese Schutzmechanismen sind wie auch die anderen. Da gibt es Möglichkeiten, das zu umgehen. Denn Doppelgänger zum Beispiel überwacht ja den Dynamischen Speicher gar nicht. Das heißt, wenn da bösartiger Code dynamisch reingeladen wird, dann wird Doppelgänger das nicht bemerken. Und bei AutoscopyJR wird das ja gegen eine statische Liste verglichen, die im Learning Mode erzeugt wird. Und wenn eine Attacke, die im ersten Schritt quasi nicht überwacht wurde, dann kann man auch das umgehen. Und unsere Attacke modifizieren die Logik nicht, und auch die Firmen werden nicht. Aber das ist grundsätzlich möglich. Und mit der Variante, die ein RootKit benutzt, da gibt es hier einen Graph der Fluktuation der Ein- und Ausgabe. Also wie heftig fluktuiert das. Und klar, also wir führen zusätzliche Arbeit aus auf der SPS. Also könnte es eine gewisse Veränderung geben. Und wir sehen, dass es ungefähr 0,5 Millisekunden oder vielleicht auch eine Millisekunde extra. Aber die Sache ist die, dass die Fluktuation von Ein- und Ausgabe weniger ist als das, was die Laufzeitumgebung der PLC selbst verursacht. Und das hat uns überrascht. Und jetzt schauen wir uns auch noch den Overhead an, also welche zusätzliche Arbeit hier passieren muss. Und das war nicht gut, also insbesondere für Lesemanipulation. Denn wir wollen ja nicht nur das verändern, sondern es soll auch so sein, dass der Operator selbst, also der Mitarbeiter, das gar nicht sehen kann. Das heißt, wir wollen irgendwie den, also wenn wir etwas ändern, dann würde sich ja auch das, was zurückgelesen wird, ändern. Und das wollten wir nicht. Wir wollten, dass der Mitarbeiter das nicht sehen kann. Wir wollten das manipulieren, aber es war nicht akzeptabel. Das waren 23, 24 Prozent Overhead. Und was wir jetzt gemacht haben, ist, wir haben jetzt, deswegen haben wir drüber gesprochen, das ohne Route zu machen, weil das eben sehr teuer war. Und jetzt gab es eine zweite Variante. Und jetzt haben wir gesagt, na gut, die Laufzeit möchte, die beschreibt eine ganze Menge Sachen, also die Konfiguration der Pinnen und so weiter. Warum benutzen wir nicht eigentlich nur die Privilegien von dieser Laufzeit, um dasselbe zu machen? Und wir können da mit dem Overhead von weniger als ein Prozent denselben Effekt erzeugen. Also wir können zum Beispiel Shellcode benutzen, wir können Devmem oder die Treiber für Geräte benutzen und damit kann man die Konfiguration manipulieren. Wie das funktioniert ist, der Unterschied zu den bisherigen Angriffen mit dem Route Kit ist, ihr müsst jetzt irgendwas, was die Anfangszeit referenziert benutzen. Also wir nehmen zum Beispiel, wenn wir es einfaches haben, wie eine LED, die alle fünf Sekunden an und ausgeschaltet wird, aber was wir wollen ist, dass wir wissen, an welchen Punkt diese fünf Sekunden anfangen. Das heißt, ich weiß, es fängt alle fünf Sekunden an, aber ich muss jetzt wissen, in welchem Moment beginnen diese fünf Sekunden. Und das ist was, was ihr irgendwann mal auslesen müsst für ein paar Sekunden, die ein Ausgabe pins und dann wissen wir, was diese Verzögerung ist, an welchen Zeitpunkten das tatsächlich passiert. Und wenn ihr das gefunden habt, dann ist es ganz ähnlich. Also wir setzen den Pin einfach auf den Input-Modus, der Schreibzugriff wird ignoriert, die PLC schreibt dahin, es funktioniert nicht, und dann ändern wir den Pin wieder zurück und auf den Wert, den wir gerne hätten. Also es funktioniert ganz ähnlich wie bei dem Schreibeding, da setzen wir es einfach auf Ausput-Mode und dann liest die PLC einfach den Wert, den wir dahingeschrieben haben. Und was wir bislang gesagt haben, da ging es um digitale Dinge, also Pin-Konfiguration und so weiter. Und die Frage ist, was ist denn jetzt mit Analogakontrolle und was hat es jetzt mit dem Pin-Multiplexing zu tun, was die physikalische Verbindung unterbricht. Und das funktioniert tatsächlich sehr gut. Also wir können die Pin-Multiplexing-Attacke benutzen, um den kompletten Analogenspeicher zu manipulieren, sodass er komplett unerreichbar ist für die Laufzeit der SPS. Und später geben wir die Kontrolle wieder zurück. Das heißt, das ist eine der Sachen, die wir machen können und das kann sehr umfangreiche Änderungen. Ich kann zum Beispiel den Programm-Counter so ändern, dass er zur richtigen Operation springt, also wegspringt von der richtigen Operation. Aber grundsätzlich ist das ganz ähnlich wie beim digitalen. Also es gibt verschiedene Bits, die wir modifizieren. Und jetzt kommt unsere letzte Demo, bei der es um Analogemunipulation eines Motors geht. Wir benutzen wir den Pin-Multiplexing, hier benutzen wir den Pin-Multiplexing-Angriff. Und hier seht ihr ein Motor, der alle paar Sekunden rotiert. Und dieser Wert, den ihr hier seht, ist minus 0,329. Das stellt eine Sinus-Fälle dar. Das heißt, der Wert geht rauf und runter und rauf. Das zeigt uns, wie wir den Motor steuern. Man sieht hier, der Motor rotiert, basierend auf dieser Steuerung. Und jetzt entscheiden wir, wann wir den Motor stoppen wollen, wann immer wir wollen, über die Analogendaten. Wir starten unseren Loader. Und was man jetzt hier sieht, der Motor bewegt sich vor und zurück, aber in Wirklichkeit ist er gestoppt. Ich gehe ein bisschen zurück. Noch mal. Der Motor bewegt sich, wir laden den Angriff und der Motor hört auf zu arbeiten, aber die Werte in der Steuerung zeigen immer noch, dass der Motor sich vor und zurück bewegt, obwohl er das tatsächlich nicht tut, weil wir haben den Pin physikalisch über den Multiplexer getrennt. Und es gibt keinen Feedback darüber. Es gibt andere Möglichkeiten für Angriffe und die schlaue Leute herausfinden könnten. Man kann zum Beispiel die Pull-up-Pull-down-Resist-Widerstände an den IOS benutzen. Und es gibt die Möglichkeit, dann gibt es die Möglichkeit, dass vielleicht jemand aus der Ferne über elektromagnetische Felder die Werte ändern kann, über Filter, über die Umgebung. Wie auch immer, wir glauben, ihr könnt euren Inputs nicht trauen, die von den IOS kommen. Und was wir glauben, ist, dass im Moment macht es eigentlich keinen Sinn, unseren Angriff durchzuführen, weil es gibt so viele einfache Dinge, die man im Moment tun kann. Wir haben jede Menge angreifbare SPS, die schon keine grundlegenden Sachen schutz haben, wie zum Beispiel die M-Backdoor-Passwort gesetzt haben. Oder es gibt keine ... Aber die Hersteller arbeiten daran. Und das heißt, unser Vortrag ist nicht über jetzt, sondern hier geht es darum, was in 2020 ungefähr passiert. Weil dann, wenn diese Schutzmechanismen eingesetzt sind, dann wird unser Angriff relevant. Also, die Probleme, die es jetzt gibt, sind leicht für die Hersteller, um anzugehen. Aber wenn das alles mal abgeschlossen ist, dann wird der nächste Schritt sein, die Laufzeitumgebung zu manipulieren, und zwar ohne Hux. Und wenn man mehr, wenn man komplexere und aktivere Verteidigungsmechanismen hat, dann gehen Angreifer auf eine andere Ebene. Und das ist was unser Angriff macht. Zusammenfassend, wir müssen uns wirklich auf Systemlevel-Sicherheit von Kontrollgeräten konzentrieren, weil im Moment haben wir wirklich keine guten Verteidigungsmechanismen. Und die Angreifer werden natürlich mit was neuem kommen. Es ist immer ein Katzen-Maus-Spiel. Und die Pin-Control-Angriff ist so ein Angriff. Und Majid, hast du eine Lösung für uns? Nein. Also, bevor man sich darüber über diese Art von Angriffen Sorgen macht, sollte man erst mal sein Standardpasswort ändern. Und tatsächlich ist es schwierig, eine endgültige Lösung zu präsentieren gegen diese Art von Angriffen. Eine gute Lösung gegen diese Art von Angriffen braucht eine gute Zusammenarbeit zwischen den Software- und den Hardware-Herstellern. Aber man kann es schwieriger machen. Zum Beispiel kann man IOS nutzen und man kann auch die IOS nach Anomalien überwachen. Und mit dieser Art von Aktionen kann man also die Angriffspfläche minimieren. Und ihr könnt gerne unsere Präsentation später nochmal anschauen. Okay, alles was einen Anfang hat, hat ein Ende. Danke fürs Zuhören. Und wenn irgendwelche Fragen sind, jeder zeigt gerne. Thank you Ali and Majid. If you have questions, please do line up at the four microphones here in the hall. If you are leaving, please leave through the front door. And leaving, please only through the front door. We have one question from the microphone up front. Es gibt eine Frage vom Mikrofon vorne. Danke für diesen interessanten Vortrag. Ich habe eine Frage. Verzeihung, bitte. Wenn ihr rausgeht, dann macht es bitte ruhig. Meine Frage ist, wie führt ihr den Code auf der SPS überhaupt aus, um die multiplexen Ritscher oder die IOS zu manipulieren? Um multiplexing zu ändern, da muss man tatsächlich Ruht sein. Da muss man im Kernel sein, um die multiplexing Angrafe auszuführen. Ohne Ruhtzugriff geht das nicht. Aber für die Pin-Konfigurationsangriffe, da kann man das ganz einfach machen. Denn eine ganze Menge von diesen SPSen, sagen wir es mal so, es gibt verschiedene IO-Busse, die an den SPS angeschlossen sind. Und was die haben ist, es gibt verschiedene Arten, also verschiedene Arte von Bussen, die über diese Pin-Konfiguration drüber kommunizieren. Es gibt also noch einen zusätzlichen Abstraktions-Layer auf diesem Konzept. Und was du machst, ist, du kannst diesen Abstraktions-Layer angreifen, in dem du also statt direkt auf die Konfiguration zuzugreifen, das geht nicht. Und nochmal, also bei Pin-Multiplexing, das funktioniert nicht. Da muss man Ruhtrechter haben. Der Kernel erzwingt das. Ursprünglich war Pin-Multiplexing beim Buten gemacht. Also der Bootloader macht das. Aber wenn man das machen will, also wenn ihr Ruht seid, dann hindert euch nichts daran. Aber man braucht eben Ruhtzugriff. Es gibt noch einen? Okay, das ist wirklich interessant. In dem Fall sieht es aus, als könntet ihr immer erfolgreich sein. Aber... Es sieht aus, als wäre Demo-Code... Es würde so aussehen, als würde dir immer nur M-Map aufrufen und das dann direkt modifizieren. Und nee, das ist tatsächlich nicht. Also bei unserer Demo haben wir mit der echten SPS, da machen wir überhaupt keinen Mapping. Sondern was wir machen, ist, wir greifen eine andere Kommunikation an, die auf dem Pin-Kontroll-Subsystem aufbaut. Also wir greifen hier nicht direkt das Ding an, sondern wir greifen einen Abstraktionslayer an überhaupt das Pin-Kontroll-Subsystems. Und so machen wir das. Aber wie wir das schon gesagt haben, was anderes, was man auch machen kann, was man auch ausnutzen kann, ist, man kann das Mapping auch ausnutzen von schon gemapten IO-Adressen, um die Attacke auszuführen. Also ist das spezifisch zu der Anwendung? Also gibt es einen internen Schlüssel für diese Ereignisse und ihr fangt den ab und nutzt den aus? Ja. Also wenn ihr keinen Ruhtzugriff habt, dann ja. Aber wenn man ein Ruhtzugriff hat, dann kann man andere Sachen machen. Und was ich viel gehört habe und viele Leute, die diese Frage gestellt haben, eigentlich, wenn ich schon ein Ruhtzugriff habe, warum will ich das überhaupt machen? Und der Punkt des Folgen, ihr geht einfach nicht davon aus, dass wir aktive Verteidigungsmechanismen haben. Also wir haben Schutz gegen Hooking in der SPS im Kernel. Also was wollt ihr dann tatsächlich machen? Was ist die Alternative? Und was wir sagen, ist, dann fasst das einfach nicht an. Fasst nichts an, was das Software betrifft. Sondern was Einzige, was wir machen, ist, wir ändern nur die Konfiguration der Pins. Und dann können wir den selben Effekt erzeugen. Das ist das, was wir machen. Und das ist ein Zeitpunkt, wo dann unsere Attacke sinnvoll ist. Wenn ihr also kein Default-Passwort habt, wenn ihr keine Checksum habt, warum macht es keinen Sinn, das alles zu machen. Das ist sehr anstrengend. Wenn man einfach diese Register zu Modifizieren hat, dann ist das einfach so, dass man die Pins, wenn man die Pins, wenn man die Pins, wenn man die Pins, wenn man die Pins, wenn man die Pins, wenn man die Pins, wenn man die Pins, wenn man die Pins, wenn man die Pins, wenn man eine Register zu Modifizieren. Aber wenn es aktive Verteidigungsmaßnahmen gibt, dann macht es plötzlich total Sinn. Dann ist man plötzlich viel eingeschränkter, seinen Angreifen durchzuführen. Es gibt noch eine Frage aus dem Internet. Guck mal, gibt es irgendein Beweis oder ein Hinweis, dass dieser Angriff tatsächlich genutzt wird? Nein. Ich weiß davon nichts. Es gibt noch eine Frage. Also wird noch mal nachgefragt. Es geht um GTag Boundary Scans. Also ob hier... Nein, also das gibt es gar nicht. Also das machen wir jetzt als Verteidigung. Ein Master Student hat damit angefangen, der macht das gerade. Aber nein, wir haben das nicht gesehen. Das gab es nicht. Zumindest in den aktuellen Embedded Systemen oder auch bei den Speicherprogrammieransteuerungen. Wenn ich mal eine SPS programmiere, ist es möglich, den IO-Modus der PINs als Verteidigung selbst zu überprüfen? Nein, das geht nicht. Es ist ja nicht die einzige Möglichkeit, die ein Attacker wie ein Angreifer... Also es gibt verschiedene Möglichkeiten wie ein Angreifer, die IO-Konfiguration manipulieren kann. Und eine Sache, die ihr machen könnt, ist, ihr prüft einfach, wie häufig sich die Konfiguration ändert. Denn in einem tatsächlich physischen Prozess, da sollte das nicht so häufig sein. Also wenn ihr also Memory Forensik Modus habt, wie hier in einem anderen Talk schon war, diese Speicher Forensik Schutz, das kann man sehen. Aber was man halt nicht sieht, also was man sieht, ist halt nur die Konfigurationsänderung. Was ist dann jetzt beim PIN-Multiplexing? Da wird nur ein Bit umgefallen, also geändert. Es wird nur eine 0 zu einer 1 geändert. Und dann ist es komplett entkoppelt. Und man sieht also sehr wenig, was man machen kann, um das zu bemerken. Also es muss noch eine zusätzliche Verteidigung geben für PIN-Multiplexing. Und was ist, wenn der Angreifer den IO ummappt? Also wonach suchen wir? Denn der Angreifer könnte ja vielleicht den IO einfach nochmal ändern. Und dann müsst ihr diese Funktionen hucken, damit man erkennen kann, was der Angreifer hier überhaupt gemacht hat. Also es gibt da eine ganze Menge mehr Dinge, nicht einfach nur um zu schauen, wie häufig sich die Konfiguration von der SPS geändert hat. Ich denke nicht, dass es reicht. Und ich glaube, es muss eine Initiative geben von den Herstellern. Also insbesondere, wenn Fehler passieren beim IO. Und insbesondere auch beim Multiplexing. Also ich finde es ehrlich gesagt sehr überraschend, dass der IO nicht verfügbar ist. Es ist nicht teuer. Also zumindest ein Interrupt für Multiplexing. Denn hier wird physisch verhindert, dass du mit dem IO redest. Aber es gibt überhaupt keinen Feedback, dass der SOC sagt, hey, also was du da geschrieben hast, das ist einfach nicht verfügbar. Und das ist total irre, dass es das noch nicht gibt. Gibt es noch Fragen? Hier gibt es noch eine. Ich frage mich, ich denke über den Interrupt nach. Woher soll der Pin Configuration Controller wissen, wenn ich von... Woher soll jetzt der Controller bemerken, was der Unterschied ist zwischen einem Bus, auf dem einfach nichts passiert, oder eine abgeschaltete Konfiguration. Und es gibt halt keinen Feedback eventuell. Also es gibt zwei Probleme, die da darunter liegen. Das eine ist, sobald sich die Konfiguration ändert, es gibt keine Information vom SOC. Also der SOC sagt nicht, hey, die Konfiguration haben wir. Das andere ist, es gibt keine Konfiguration, es gibt keine Information vom SOC. Also der SOC sagt nicht, hey, die Konfiguration hat sich geändert. Das ist das eine Problem. Und das zweite ist, sobald sich die Konfiguration geändert hat und dein Schreibzugriff schlägt, dann gibt es kein Feedback. Hey, diese Schreibzugriff ist gerade fehlgeschlagen. Und was Sie also zumindest machen können, ist, hey, Sie können sagen, na gut, also diese Konfigurationsänderung, die wird mitgeteilt, so dass zumindest der Treiber oder die Software dann wissen, was die Konfiguration geändert hat, was Sie aktuell nicht wissen. Na ja, ich denke mir, wenn du Route Access hast, dann kannst du die ganze Information sowieso überflüssig machen. Oder sie ist überpflichtet. Ja, klar, wenn du rot bist. Habt ihr versucht, Sicherheits-SPS zu verwenden, so dass die Werte der IOS zurückgelesen werden müssen und wenn man ein ... Nein, solche haben wir nicht angeschaut, dass es war. Es gibt möglicherweise ein paar SPS, die das tun. Aber zum Beispiel, wenn wir sowohl für Pin-Multiplexing und Konfigurationen benutzen, wenn der Angreifer den Ausgabe ummappt, dann sieht er tatsächlich nur den virtuellen I.O., so dass hier schlägt nichts fehl. Denn im virtuellen Speicher wird es ja geschrieben. Da wird es auch gelesen. Das funktioniert ja auch. Und sobald man das überprüft, das ist richtig. Die Werten stimmen. Aber was passiert, ist, dass der physikalische Prozess, der tatsächliche Werte, der stimmt eben nicht überein. Denn in einem anderen Register, dass die SPS, zum Beispiel Level-SPS, prüfen nicht die Konfiguration, sondern die prüfen den tatsächlichen Wert. Der ist halt da, aber es hat nichts mit dem physikalischen Prozess zu tun. Und deswegen nennen wir das auch die Speicher-Illusion. Denn was man da sieht, hat nichts damit zu tun, was in der physikalischen Welt tatsächlich passiert. Es gibt noch eine Frage über Ihr C, über den Signal Angel. Oder auch nicht. Oder doch. Lass uns noch eine Frage über das Mikrofon annehmen, bitte. Also, ihr müsst ja den, das Programm der PLC emulieren. Gibt es eine Möglichkeit, die Software auszulesen aus der SPS? Und die Frage ist, ja, klar, das geht. Aber warum würdest du das machen wollen? Ich verstehe, in einem APT-Szenario verstehe ich das. Also, ihr wollt, ich meine, möglicherweise will man vielleicht die Daten irgendwie erst mal als Aufklärungsdaten haben. Aber wenn man Remote Code Accusion hat in der SPS, dieses Jahr, glaube ich, waren es fünf Lücken, die gefündet wurden. Klar, wenn du das hast, dann kannst du dir das auch auslesen, ohne dass da eine Lüge, eine Lüge, eine Lüge, eine Lüge, eine Lüge, eine Lüge, eine Lüge, eine Lüge, eine Lüge, eine Lüge, eine Lüge, eine Lüge, eine Lüge, eine Lüge, eine Lüge, eine Lüge, und dann ist das eine Meldung dazu passiert. Okay, die Zeit ist rum. Vielen Dank. Danke, das ist Jan Magid.