 Sicherheitslücken finden im Cisco IOS und das am allerersten Tag. In der Übersetzungskabine setzen für euch Kaste und Farmerfärmer. Wenn ihr Feedback zu den Übersetzungen habt, könnt ihr das geben zum Beispiel per Twitter an Ich wiederhole ad C3Lingo oder unter dem Hashtag C3T. Der Speaker wird zur Zeit vorgestellt. Im letzten Jahr haben wir viel über Sicherheitslücken in Cisco Produkten gehört und ich bitte jetzt einen großen Applaus für Artem Kotradenko. Hallo zusammen, ich bin sehr aufgeregt um hier am Kongress zu sein. Schön, dass ihr alle da seid. Ich werde euch etwas über praktische IOS-Ausnutzungen, Sicherheitslücken suchen, erzählen. Ich mache Penetration-Tests. Ich mache auch Sicherheitsforschung in meiner Freizeit. Dieser Talk ist eine Fortsetzung von meinem Talk, den ich bei Defcon gehalten habe. Für alle, die das nicht mitgekriegt haben, ich fasse kurz zusammen, was dieses Jahr alles geschehen ist. Im Jahr 2017 wurden viele Sicherheitslücken gefunden. Wir haben drei Sicherheitsadvisories publiziert. Das erste ist eine Verwumpaukeit, eine Lücke im Klostermanuschen-Protokoll, dann eine Cod-Ausführung über einen Assen-AMP und eine ähnliche über DHCP. In diesem Vortrag werde ich über zwei von den drei Lücken sprechen, über die ersten zwei, weil die dritte ist noch in Untersuchung. Am Ende werde ich euch eine Live-Demo zeigen. Also, was bisher geschah? Im März 2017 gab es eine Sicherheitswarnung von Cisco, dass sehr viele Switches von Cisco anfallig waren und es war aber kein öffentlicher Exploit verfügbar. Die wichtigsten Punkte dieser Lücke waren folgende. Cisco Switches kann in einem Kloster zusammengeschaltet werden und dafür gibt, um die zu managen, ein Kloster-Management-Protokoll, welches auf Teil nicht passiert. Da gibt es verschiedene Optionen, wie man das senden kann und was es wichtig ist, dass das Protokoll wird quasi interpretiert, auch wenn die Cisco Switches nicht in diesem Kloster-Modus sind. Die Quelle von dieser Forschungsarbeit war eine Cisco-Internet-Untersuchung und eine Untersuchung, welche in WikiLeaks gepostet wurde. Also, bis auf die Advisory, also die Warnung, die rausgegeben wurde, kann man einfach auf WikiLeaks gehen und sich dort anschauen. Im Prinzip sind das die Notizen eines Mitarbeiters von Cisco, der das selber ausprobiert hat. Es funktioniert ungefähr folgendermaßen. Es gibt zwei Möglichkeiten, damit sie interagieren. Entweder der Angreifer verbindet sich mit TANET und macht einen Overflow-In-Service, also ein überlastetes, für alle Subsecret-Connections, die folgenden Verbindungen mit TANET werden dann ohne Rechteabzufragen ausgeführt. Das haben wir präsentiert auf der DEF CON 25. Das Ziel war der Cisco Satellis 2060 und wir haben darüber geschrieben, wie man es debacken kann. Wenn ihr meinen Blog lesen wollt, wie man das ausnutzt, ihr könnt auch auf GitHub schauen. Heute will ich aber etwas anderes lesen. Es gibt eine neue Lüchge, die dieses Jahr veröffentlicht wurde. Da geht es um SNMP aus Führungen. Die Motivation war, dass ich selber einen Lücken-Test, einen Tentest durch den Cisco Router, das hat ein Cisco 2811-Mutter vorgebracht, der mit den Defaults lief. Und mein Ziel war es, zu Luft hochzukriegen. Der Angreifer braucht einen nur lesbaren, aber nicht schreibbaren Mute-String, das ist ein sehr common Device. Dieser Cisco 2811-Mutter ist ziemlich häufig, der kommt relativ häufig vor, verwendet MIPS. Es gibt keine Klein-Tools, um das Ding zu debacken. Die Firmware ist aber relativ neu. Es ist relativ interessant, um sich die Abwehrmechanismen anzuschauen. Relativ neu heißt in dem Fall, es ist eigentlich schon aus dem Support rausgelaufen. Das heißt, das unterstützt es gar nicht mehr. Der letzte Patch kam 2016 raus, um euch dann zu erinnern, die Warnung für den SNMP Overflow war 2017. Der Patch ist schon älter und die neue Dickel ist nicht gepatched worden. Es ist aber ein relativ weit verbreitetes Gerät. Wenn man in Schodern sucht nach 3313, findet man das sehr oft. Die sind alle mit dem Default-Public-String verfügbar. Die meisten davon dürften für den SNMP Overflow anfällig sein. Wir haben uns gedacht, okay, ich will einmal kurz zusammenfassen, wie es funktioniert. SNMP kommt mit vielen Abbrevationsen, wie MIB, die für Information-Base ist. Das SNMP hat MIB, das heißt, um das OED, wo man diverse Informationen abrufen kann. Ein Beispiel für OEDs ist, ich kann zum Beispiel Netzwerkdrucker, die unterstützen meistens SNMP. Zum Beispiel, um anzuzeigen, wie viele Tinte oder Toner noch übrig sind. Das Ganze ist in einer Baumstruktur aufgebaut. Ihr seht oben das Basis-Rement und dann die Plata, dieses Baumes. Eine Anfrage funktioniert folgendermaßen. Das muss man auch um die Deluxe auszunutzen. Man muss diesen Textbaustein nehmen und dann kriegt ihr ein Resultat zurück. Hier in diesem Beispiel holen wir zum Beispiel die Hardware-Versionsnummer zurück. Das kann man dann mit einem Linux-Tool machen. Das sieht zum Beispiel so aus. Aber was müssen wir zuerst machen, bevor wir etwas anfangen? Wo können wir denn jetzt anfangen? Die Sicherheitsadvisorie sagt, dass neun von diesen am IBS verrundbar sind. Jetzt machen wir alles etwas fassig. Wir probieren diverse Sachen aus mit dem Skape, mit diesem Toolkipp. Das heißt so. Wir senden damit verschiedene Pakete. Wir fangen mal an mit Buchstaben A zu senden. Dann macht er wieder ein IP-Packet, ein ASAN-AMP-Packet usw. und senden das an den Switch-Router. Den Überlauf kann man jetzt irgendwann mal triggern. Wie kriegt man denn jetzt diese OIDs aus der Firma? Die OIDs in der Firma sind gespeichert als plaintext. Die findet man relativ einfach heraus, aus einem Beinritz zum Beispiel. Was man auch anschauen kann, ist die Verwumparkheiten im MIPS handzuschauen und auf den Webseiten findet man die. Das erste Mal muss man den Router mal zum Abstil springen. Das ist aber jetzt nicht der Fokus unserer Untersuchungen gewesen. Die eigentliche Overflow war in einer dieser Dateien, die wir gefunden haben. Das ist die, die letztlich den Router zum Abschutz gebracht hat. Wenn man sich mit einem Serial-Cable mit dem Router verbindet und wenn man einen Crash hat, dann kriegt man einen Stack-Chase. Hier sieht man einen korrumpierten PC-Register, also einen Program-Counter-Register. Das heißt, in dem Moment haben wir die volle Kontrolle über den Program-Counter. Hier sieht man, dass wir die Kontrolle haben. Das heißt, IPC in dem Fall. Und wir kontrollieren auch die Inhalte der Register 0 bis 6. Und ich habe auch noch 60 Bytes auf dem Stack, die ich benutzen kann. Vor wir jetzt anfangen, den Explod wirklich aufzubauen, müssen wir auch ein paar Probleme lösen. Wir kontrollieren den Program-Counter, aber wo wollen wir denn hinspringen eigentlich? Ist Adress-Based Layout Randomization, also Verwirflung des Adressraums, ist der Stack im Zweifelsfall ausführbar, oder ist Caching von Daten an? Können wir unseren Shell-Code direkt, also unseren Shell-Payload auf den Stack schmeißen? Können wir den Code selber patchen, also ist die Abteil, also die Sektion im Binary schreibbar? Wie können wir den Flow, also den Programmablauf umbieten, wenn das Binary im Rahmen läuft? Wenn man da einen Fehler macht, crasht einfach das Operating-System an dem Fall. Also ist fast dazu führt, dass das Gerät einfach neu laden wird. Das heißt, unser Ziel ist jetzt, die Lücke auszunutzen, ohne dass wir dabei das Gerät crashen. Bevor ich mich jetzt auf die Firma erstürze, dann möchte ich noch einmal kurz auf die vorangegangene Forschung dazu referenzieren. Diese Untersuchung hier hat mir sehr geholfen, also das war sehr erhellend. Wie solltet ihr euch mal anschauen, wenn ihr euch dafür interessiert? Also zum Beispiel Router Exploitation von Felix Lindner auf der DevCon, Cisco-IOS Shell-Code, oder How to Cook Cisco. Da geht es darum, wie iOS sich bei Ausnutzung von Lücken verhält. Das ist eine großartige Info, um PowerPC-Plattformen zu verstehen, bei Cisco und um das bei iOS auszunutzen. Wenn ich euch jetzt erklären würde, wie iOS wirklich aussieht, müsste ich sagen, es ist am Ende des Tages einfach ein komplett statisch zusammengelingtes Binary, was im Spiel hier liegt. Es gibt keinerlei API, klar. Deshalb keine Symbole. Ja, es gibt eine G-Lib C, also am Ende der Vineer-Datei, aber es ist schwierig zu benutzen, weil es gibt so viele verschiedene Firmware-Versionen und jedes hat einen anderen Off-Site und dahin zu springen ist sehr schwierig, weil man weiß nie genau, wo sie gerade sitzen. Am einfachsten ist es, man kopiert einfach die Firmware aus dem Router, die raus ist. Es gibt einen Kommand, der heißt Copy. Mit dem kann man das aus dem Raum rausladen. Und das nächste, was man dann machen muss, ist die Auspacken. Die Firmware ist selbst, hat ein Anfangsteil, der den Hack-Algorithmus ausführt. Man kann einfach Binwalk machen und das führt das für einen aus. Das resultierende kann man dann ausführen, aber man muss den Typ ändern zu MIPS 32-Bit. Das wissen wir schon, dass es MIPS ist, weil wir haben die Register gesehen und die Register sind typisch für mit. Okay, eins möchte ich mal vorausschicken. Die Firmware wird in eine bestelle Adresse im Ram geladen. Aber der Firmware sitzt auch an einem anderen Punkt im Ram. Das sieht daran, dass die Firmware die Adresse ummeppt. Das muss man beachten, wenn man es hinterher in IDAPRO ausführen will, weil wenn man es nicht rebased, laufen die Sprunger ins Leere. Das heißt, man muss die Querverweise nach dem rebased selber korrigieren. Um die Lücke ausnutzen zu können, geniegt es natürlich nicht, sondern man muss einfach nur IDAPRO ausführen und die Querverweise korrigieren. Man muss wirklich eine Debugumgebung aufsetzen. Jeder weiß oder viele wissen, dass man das über den Serial Import machen kann. Da gibt es sogar ein GDB Kernel-Kommand, mit dem man den GDB Server, der in iOS mitgeliefert wird, auf dem Gerät starten kann. Das wurde zwar kürzlich entfernt aus den neueren Versionen von iOS, aber es gibt trotzdem einen Weg, die Automone zu kommen. Man muss nur das Gerät neu starten, eine bestimmte Escape Sequence schicken, also mit dem Kommand, den er auf der Folie hat, und damit bekommt man eine Shell. Das wird dann geladen, bevor die GDB Server ausgeführt wird. So könnt ihr jetzt manual eure Firmware starten, mit Flags, wie ihr möchtet, und da gleich GDB mit starten. Und sobald die Firmware geladen ist, wird GDB auch starten und in Betrieb sein. Ihr könnt einfach euren Lieblings-GDB von Linux benutzen, weil GDB benutzt einen anderen Kommando-Subset von den GDB-Kommandos. Der Client muss dafür etwas angepasst werden, an den Server, welcher im iOS läuft. Es gibt offiziellerhaltliche Debugging-Tools für iOS, die sind aber eigentlich vorgesehen für Cisco-Engineure. Also nein, es gibt keine öffentlich verfügbaren, aber es gibt eine Community, welche versucht solche Tools zu erstellen. Also ihr werdet ziemlich sicher die finden, wenn ihr dann auch sucht im Internet oder ein Tutorial. Aber es funktioniert dann effektiv eigentlich nicht, weil ich habe versucht, eine alte Version zu versuchen, das hat nicht funktioniert. Es gibt ein cooles Tool, das ist iOdit. Das ist ein grafischer Debugger für iOS. Das ist eigentlich ein großartiges Tool, aber es ist für PowerPC-Architektur. Wahrscheinlich müsst ihr ein Debugger zuerst noch patchen, um damit arbeiten zu können. Und die letzte Option wäre jetzt, einen eigenen Debugger zu implementieren für diesen Debugger. Dazu müsst ihr wissen, welche Kommandos ihr effektiv, Cisco-effektiv unterstützt. Und das sind halt Read-Memory, also Speicherlesen, Speicher-Schreiben, den Programmkonto, Counter-Kontrollieren und dann. Und also es ist schlussendlich eigentlich relativ einfach, so einen Debugger zu schreiben, weil alle Informationen in Klartext über das serielle Kabel gesendet werden und es hat nur noch eine Check-Summe dran. Und so konnte ich das machen, einen kleinen Peinten-Skript schreiben, welches mit wem man jetzt iOS debaggen kann und Register anschauen und so weiter. Man kann Schritte überspringen, Schritte einfügen und so weiter, Memory-Speicher auslesen und so weiter. Also jetzt wollen wir ja den SNMP Overflow, die Pufferüberlauf finden und ja, der ganze, dazu suchen wir nach Referenzen innerhalb von dem Code und von der SNMP Anfragen bis das Crash, aber eben, wir wollen ja nicht unbedingt das Gerät zum Absturz bringen, sondern, ah, okay, man kann das Gerät zum Absturz bringen und dann den Speicher auslesen und dann dies analysieren. Das gibt dann einen Hinweis darauf, wo der Crash wirklich passiert ist. Die Korruption des, oder dieerschreiben des Program-Counters passiert hier. Am Ende der Funktion laden wir die Werte aus dem Stack wieder in die Register 0-6 in das RA-Register. Das ist wichtig. Das ist das Rücksprung-Adressen-Register. Das heißt, das wird benutzt, um wieder zurück zu der aufrufenden Funktion zu kommen. Das heißt, wir haben ein bisschen Platz auf dem Stack. Die Frage ist, können wir da unseren Sharecode, also unseren auszuführenden Code dort platzieren und ausführen? Das Problem ist, dass der Ort, wo der Stack liegt, ist nicht so ganz vorhersagbar. Man kann es wirklich schwer vorhersagen oder beeinflussen. Es gibt keine validen Instruktionen in der Instruktion, mit dem man dahin springen kann selbst wenn wir sie finden würden. Der Adressraum wird randomisiert und deswegen sind die Code und die Daten immer wieder an verschiedenen Funkten im Speicher. Dummerweise ist auch noch Data Caching an. Hier sieht man die Adressraum-Randomisierung. Ich habe vorhin viel gesagt über die Unterschiede der verschiedenen Firmware-Version. Am Ende sind es so viele, es wäre schwierig, irgendwo zuverlässig hinspringen zu können. Aber hier haben wir die Adressraumverwirflung und das heißt, der Text 16 ist jedes Mal woanders. Das andere Problem ist das Data Caching. Wenn wir unseren Code auf den Stack schreiben, dann gehen wir davon aus, dass es da drauf liegt. Aber was wirklich passiert ist, es wird in den Cache geschrieben. Das heißt, wenn wir unseren Programmzähler auf den Stack schreiben, dann kann es passieren, dass es trotzdem wieder in den Cache endet. Das ist am Ende eine Gegenmaßnahme, dass man Daten ausführen kann und nicht nur Code. Das soll Return-Oriented-Programming verhindern. Das heißt, dass man mit den Rückspringen unsyntreiben kann. Das Problem ist, dass es jedes Mal an einem anderen Offset liegt und die Spiecher-Layout-Randervisierung sogar hilft. Das erste, was wir jetzt brauchen, ist, dass wir wissen, wo diese relativ rudimentäre Firmen im Speicher liegt. Wir haben jetzt Rommmon, das ist ein interner Disassembler, der uns hilft, beliebige Adressen in die Situation sammeln. Wenn man jetzt ungültige Speicheradressen eingibt in diesen Disassembler, dann kriegt man einen Stack-Chase. Das Interessante daran ist, dass der Rommmon einer bestimmten Adresse liegt und man kann es mit dem Debugger rausdampen. Oder man sucht sich die Firmen mit der richtigen Version und sucht sich dann die richtig raus und zieht sie daraus. Das Interessante daran ist, dass Rommmon immer an derselben Stelle ist und es auch über Neustarts hinweg an der gleichen Stelle bleibt. Das ist super, wenn man damit eine Return-Oriented-Programming-Kette aufbauen will. Das heißt, wie bauen wir jetzt den X-Leute auf? Wir springen an Rommmon hin, wir starten eine Kette von Return-Oriented-Programming und danach müssen wir den Stack-Frame wiederherstellen um danach den Fluss wieder zurückzulenken, in die geordnet waren, wie sie eigentlich gewesen wären. Der dritte Schritt führt dazu, dass wir das mehrfach ausführen können und das hilft uns dann am Schluss, genug Daten zu schreiben und dann wirklich Shellcode im Speicher aufzubauen. Wenn wir den dann wirklich aufgebaut haben, können wir hinspringen, aber das dauert ein bisschen. Hier haben wir mal einen Überblick darüber, wie es funktioniert. Das ist jetzt ein schneller Überblick über den Stack-Vier aufgebaut. Wir springen in den Rommmonitor, wenn wir da was finden, was die Daten auf dem Stack benutzt, so dass wir einen vierweiten großen Stückchen Speicher schreiben können. Dann suchen wir ein weiteres Stückchen Code im Rommmon, mit dem er das zurück springen kann. Das ist jetzt ein Überblick darüber, wie man einmal komplett rumläuft durch diesen Zyklus, um vierweiten zu schreiben. Was ist das Return-Oriented-Programming überhaupt? Wie funktioniert das? Die Idee ist, wir führen nicht den Shellcode direkt aus, sondern wir benutzen existierenden Code im binary in der firmware, um unseren Payload tatsächlich auszuführen. Es gibt verschiedene Instruktionen, die man da benutzen kann, um unseren Stack quasi als Code auszuführen. Es gibt verschiedene Codes, Codes Ausschnitte, die man da zusammensetzen kann, um das zu bewerkstelligen. Daran gibt es zwei. Es gibt zwei anderen Forderungen. Der Payload muss irgendwie ausgeführt werden und der Code muss irgendwie weitergeleitet werden oder wenn es das letzte dieser Teilstücke ist, dann muss das zum Code, den wir in den Assen-AMP-Server senden. Das Problem ist, dass es nur eine limitierte Anzahl von diesen Gatschets gibt, die man Kurschnüpseln gibt, die man benutzen kann. Zum Beispiel der Rommmonitor, der Rommmon, der ist nur 500 Kilobytes und es gibt nicht so viel. Das zwei größte Problem ist, die meisten davon sind Funktionsplöcke, die mit dem Stackframe heromantieren. Das muss man berücksichtigen, weil sonst crusht das Ganze, wenn das Stackframe versehentlich kaputtgemacht wird. Was wir jetzt meistens schreiben, wir dann irgendetwas in den Speicher und dieser Code würde dann ausgeführt. Wenn wir solche Gatsche suchen, um den Code auch zu werden, dann schlagen wir an erstes, wo man mal den Code reinschreiben kann und der zweite muss dann den Code in den Register schreiben oder in eine Adresse, damit man darauf zuspringen kann, wenn ich es richtig verstanden habe. Wir wollen jetzt Gatschets finden, welche auch Daten vom Stacklan und ins Return-Register schreiben, um das nächste Gatschet aufzurufen. Wir müssen nicht manuell nach diesen Gatschets suchen. Es gibt verschiedene Tools, mit denen man solche Rob-Ketten bauen kann, zum Beispiel Robber, das er bei dem Link findet und das sucht nach diesen Instruktionen, die man braucht, um so eine Rob-Kette bauchen zu können. Jetzt gehen wir mal zum Rob-Mon, der letzte technische Teil, zu den Rockchains und am Schluss gehen wir dann zu der Demo. So sieht ein perfekt gültiger Stackframe aus, ein gesundes Stackframe. Man hat lokale Variablen, man hat Rücksprung-Adressen und darunter sind die Stackframes von den aufrufenden Funktionen. Wenn wir jetzt einen Überfluss, einen Overflow machen, dann schreiben wir, ja, dann das passiert dann, wir überschreiben lokale Variablen und das wird dann in diese Allgemeinregister geschrieben und wir überschreiben damit ebenfalls die Rücksprung-Adresse und haben nachher irgendwie, ja, wir überschreiben auch noch das Stackframe von der nächsten Funktion, um genügend Daten zu haben für unsere Rockchain. Zum Beispiel hier kann man, also ich kann auch das S0-Register vermanipulieren und es gibt nur wenige Gadgets, die das S0-Register benutzen und darum ist das zu davon. Also der wichtigste Teil ist, man muss die Rücksprung-Adresse von unserer Rockhead irgendwo hineinladen in diese Rücksprung-Register und damit das Gadget dann ausgeführt wird. Wenn das Gadget fertig ist, dann zeigt S0 in den Speicherbereich, wo wir hinschreien wollen und V0 in den Speicherbereich, also auf die Adresse zu sprechen, wo wir davon lesen wollen. Das letzte Gadget macht jetzt einen Schreibzugriff, es nimmt Daten vom Register V0 und schreibt sie da, wo S0 hinzeigt. Und das letzte, was es macht, ist es gibt die Kontrolle zurück an das andere Gadget, welches den Stack wieder herstellt für uns. So haben wir also eine Gadget-Kette, um den exploit mehrere Male auszuführen. Hier hat vielleicht gemerkt, da gibt es verschiedene Bytes im ganzen Stack, die wir manipuliert haben. Das heißt, wenn wir den Stack-Pointer nicht richtig setzen, dann wird das an die falsche Adresse zurückspringen und das ganze Wert kraschen. Und den Stack muss man entsprechend reparieren. Wir landen das Return-Register RA, das zeigt auf die aufrufende Funktion, von unserer verwundbaren Funktion, und so können wir vier beliebige Bytes schreiben. Wir können das mehrmals wiederholen in unserem Shell-Code und das kurz vor die Text-Sektion schreiben. Dann machen wir wieder einen Überlauf und springen in den Shell-Code. Das Gerät, den ich gearbeitet habe, hatte einen Telnet-Service, das einen Passwort hatte. Das heißt, ich habe einen einfachen Shell-Code entworfen, der diese Authentizierung patcht. Man hat hier eine Funktion, die heißt Passwort prüfen. Und dabei wird das von der Registration überprüft, ob die Authentizierung erfolgreich war oder nicht. Das heißt, wir wollen jetzt einen Shell-Code, der diese Anweisung überschreibt und eine Liste von Authentizierungen einzugeben, die durchgehen. Was dieser Shell-Code jetzt macht, ist, er schaut den Stack an und berechnet damit die Adress-Raumverwürfelung. Was man überschreiben will, muss man natürlich genau wissen, wo man hin muss. Nach der... Es sucht nach einem Passwort für Telnet und nach dem Passwort springt so. Und dann springt es zurück zu dem SNMP-Service mit dem normalen Codefluss. Jetzt wollen wir mal sehen, ob ich das auch live hinkriege in der Demo. Hier habe ich meine serielle Verbindung mit dem Gerät. Mir sieht ich, ich habe hier eine Shell auf. Was ich jetzt machen werde, ist, dass mit dem Passwort funktioniert oder nicht. Ich habe jetzt ein falsches Wein angegeben, weil ich den richtigen nicht kenne und es hat nicht funktioniert. Also, prinzipiell funktioniert die Prüfung. Jetzt lassen wir den exploit laufen. Das Parameter nimmt die Adresse von dem Gerät, den Community-String und den Shell-Code, den man ausführen lassen will. Das ist der Shell-Code, den ich vorhin beschrieben habe, der den die Autophizierung ausschaltet. So, let's write. Ah, ich brauche noch Sulu. So, hier sieht man, dass wir die 4-byte-Sequenzen in die Textabteilung initiieren. In den Speicherschreib. Wenn der exploit fertig ist, muss ich nur in den Shell-Code springen. Und das fragte mich hier auch. So, jetzt wollen wir mal sehen, was passiert. Bitte crashen. So, yes. Ich bin drin. Viel Applaus. Zurück zu den Folien. Natürlich kann man ein Shell-Code bauen, das ganze wieder rückgängig macht und auch das Passo wieder zurückbringt. Jetzt wollte ich mal noch kurz ausführen. Ich kann mal das ausführen. Natürlich ist die... Man kriegt irgendwie die Version raus, die als Firmware auf dem Gerät ist. Aber man kriegt nicht die Version von Raman aus und auf Raman bauen wir ja auf, deswegen ist es schwierig. Es gibt am Ende des Tages gar nicht so viele. Es gibt wirklich nur fünf für den Router, den ich anschaue. Im Stimmfall ist Crasher halt viermal und dann ist es jetzt nicht irgendwie exzessiv oder so. Aber es gibt noch eine zweite Variante, die noch besser ist. Es ist vorgesehen, dass man Raman auch upgraden kann. Das heißt, man muss eine spezielle Adresse laden und dann upgrade sich selber. Es gibt eine nur lesbare Abteilung im Speicher, wo die Originalversion immer drin liegt. Das heißt, selbst wenn man es upgradet, die alte Version wird immer da sein und immer an dieser Adresse sein, die er oben angegeben hat. Das heißt, die Annahme ist, dass alle Geräte, die zur gleichen Zeit hergestellt wurden, immer die gleiche Version haben müssten an dieser Stelle im Speicher. Das kann man jetzt mal die Seriennummer rausfinden mit dem SNMP-Get-Kommand. Meine Version ist in 2008 hergestellt von der Chechen-Republik. Das heißt, es hat jetzt die Version 12.4 preiz in ART. Um das alles zusammenzufassen, nie, nie, niemals default Passort da stehen lassen, vor allem nicht auf externen Netzwerken. Das ist eigentlich, wartet nur drauf, was ihr offen habt, welche Services ihr lauft. Natürlich müsst ihr immer gucken, wann hört der Hersteller auf, das zu supporten. Danke schon mal. Danke für die Aufmerksamkeit. Danke, Artem. Danke, Artem. Ich glaube, es gibt ein paar Fragen, aber ich habe noch eine Frage. Danke, Artem. Ich nehme an, dass es ein paar Fragen geben wird, also nehmt ein Mikrofon und es scheint niemandem Internet zu geben, der Fragen hat. Ja, wie sieht das aus mit Fragen, Fragen aus dem Internet? Mikrofon Nummer eins. Hallo, ich bin ein Netzwerk-Cutmin und ich weiß, dass Leute gerne Ascendampi verwenden auf ihren Routern. Ist das möglich? Also wenn, kann man, wenn man Rit only hat, also wenn das ist die selbe Ascendampi-Kommunik in allen Devices, davon gerade. Das Wichtigste ist, dass man sein Router upgraded. Das heißt, wenn du Geräte benutzt, die schon lange aus dem Support raus sind, dann solltest du auf jeden Fall einen sehr starken Community-Schüssel verwenden. Gibt es Fragen aus dem Internet? Ja, jetzt habe ich ein Mikrofon. Das Internet fragt, wie viel Zeit hast du insgesamt in dieses Projekt investiert? Naja, ungefähr 4 Wochen gedauert, bis ich den Exploit beieinander hatte. Vom Finden der vom Finden des Geräts im externen Netzwerk bis zum fertigen Exploit. Danke. Ich habe auch eine Frage an dich. Du hast viele Freiwillige, die mit dir arbeiten und diese Forschung unterstützen. Hast du? Nein, wir haben keine Freiwilligen. Das ist einfach nur 3-mal Arbeit. Danke vielmals für den großartigen Vortrag. Für den großartigen Vortrag. Der eigentliche Proof-of-Concept und der Debugger wird veröffentlicht. Ziemlich bald. Vielleicht in der Woche, dass du das alles rausgegeben habt. Okay.