 Heute freue ich mich, Andrej Kostin vorstellen zu dürfen. Er hat Informatik in Bucharest studiert und sein Doktor erworben vor Kurzem und er hat sich für Embedded Devices interessiert. Viele von euch haben ihn vielleicht schon mal nachgeguckt. Er ist der Autor des MyToolKits. Er redet heute über Methoden, wie man Sicherheitsanalyse auf einer großen Scala bei Embedded Devices durchführen wird. Und jetzt bitte Applaus für ihn. Hallo, everybody. Hallo, jeder. Wir kommen bei meinem Vortrag und danke für die Einführung. Mein Name ist Andrej Kostin. Ich bin ein Doktor aus Frankreich. Ich will euch heute einen Kurzabriss meiner Doktorarbeit geben über die Firmware von Embedded Devices. Wir haben auch ein paar Demos. Das ist ein Kurzabriss über mich. Ich interessiere mich für Embedded Devices. Unabhängig davon, wie sie aussehen, wo sie auftauchen. Also RFID-Chips, Kreditkarten, Drucker, System, Kameras, Flugzeuge. Das sind alles Beispiele für Embedded Devices, die quasi in verschiedenen Gehäusen leben. Es sind halt eingebettet. Daher sind sie ein bisschen anders als normaler PC. Das ist für mich interessant. Die sind heutzutage überall. Die sind nicht neu. Wir gewinnen uns langsam drauf. Wir benutzen sie jeden Tag. Wir sehen, dass Embedded Devices komplizierter, komplexer und auch intelligenter werden. Weil wir einfach wollen, dass sie nützlich ihre Dinge für uns tun. Zum Beispiel, dass man auch einfach ein Skript drauflaufen lassen kann oder eine API aufrufen. Oder sogar wirklich richtig fortgeschrittene Software drauflaufen zu lassen. Zum Beispiel, wir haben Smart Grid. Und die vernetzen sich auch immer mehr. Und das ist halt auch das neue Buzzword. Dieses extra Schicht, ein Komplexität, die wir da zufügen, die wir vorher nicht hatten. Weil die vorher auch nicht vorgesehen war, dass man die vernetzt. Und immer komplizierter Stacks und APIs macht es komplizierter, die kompletten Infligationen für die Sicherheit des Systems zu verstehen. Wir müssen einen systematischen Ansatz wählen, um das wirklich zu durchsteigen. Diese sind Embedded Devices, die ich hier zeige, egal davon, wie sie aussehen. Und die Software, die sie fahren, heißt Firmware, einfach aus historischen Gründen. Der Smart Meter, den du jetzt zu Hause habt. Der Router zu Hause, die Festplatten im Rechner, die Netzwerkkarten. Die alle haben Firmware, die sowas wie ein Minibetriebssystem darstellen für die Geräte. Es gibt jetzt schon Untersuchungen darüber. 2014 haben wir ein Teil des Internets angesehen, den beobachtbaren Teil. Und da gab es wirklich hunderttausende Firmware-Pakete, die man runterladen konnte. Und die man auch entpacken und analysieren kann. Es ist wirklich möglich, dass es noch viele, viele Tausende andere gibt. Aber wir haben schon hunderttausende gefunden. Und dann ist auch diese interessante Schätzung, dass 2014 hätte es schon 14 Milliarden im Internet vernetzte Geräte gegeben haben müsste. Bei 2020 gehen wir davon aus, dass es zwischen 20 und 50 Milliarden vernetzte Internet of Things und auch Embedded Devices geben wird. Das bringt uns dahin, dass Embedded Devices quasi überall sind. Sie sind wichtig für unser tägliches Leben. Denkt zum Beispiel an Herzschrittmacher oder an Issues. Sie können viele Jahre arbeiten, zum Beispiel, wenn sie irgendwo in Beton sind. Dann könnten sie jahrelang arbeiten, ohne dass sie Updates bekommen. Sie haben eine große Angriffsfläche, weil diese Geräte keine normale Maustastatur-Eingang-Auchgangsysteme haben, keine Monitore. Deswegen brauchen sie eine Web-Oberfläche, ein Netzwerk-Schnittstellen und debugging-Schnittstellen, damit sie leicht betrieben werden können. Es ist keine Neuigkeit, dass eingebettete Geräte unsicher sind. Diesen Trend kämen wir seit 2005 oder 2006 als immer mehr und immer häufiger Beispiele. Zuteil kamen von unsicheren eingebetteten Geräten, zum Beispiel Routern oder Druckern, die unsicher sind auf dem großen Stil, wie auch IP, Telefone oder Autos. Die, die auch heute noch hackbar sind, Drohnen, Feuerwerke, Industriesysteme. Das kann weiter und weiter gehen, weil es einfach keine Obergrenze gibt für die Anwendung von eingebetteten Geräte. Wir können uns die Forschung anschauen und sehen, dass jedes eingebettete Gerät irgendeine Schwachstelle hat. Aber was wir dabei beobachten, ist, dass die meiste Forschung von Hand gemacht wurde, nicht nur von Hand, aber jegliche Forschung wurde individuell betrieben. Also man hat ein einzelnes Gerät genommen oder eine einzelne Firmware und sie analysiert, von Anfang bis Ende. Und dabei muss man eine ganze Menge langweiliger Arbeit machen, nicht viel Handarbeit, viel Skripting. Und das skaliert einfach nicht. Wenn man wissen will, wie sicher oder unsicher 50 Milliarden verbundene Geräte sind oder Schwachstellen in hunderttausenden Firmware-Images haben will, dann brauchen wir Ansätze, die skalieren. Und das tun diese Ansätze von Hand einfach nicht. Ich würde euch eine ganz schnelle Übersicht geben, wie normalerweise Firmware von Hand analysiert wird und für viele von euch ist das wahrscheinlich nichts Neues. Aber die Idee ist, dass es ein Firmware-Paket gibt, das ladet hier runter oder habt ihr es auf einer CD oder ein Busbestick oder ihr seid hunderte Euro und kriegt es auch eine tolle SD-Karte, wenn es irgendwie ein Skada-System ist, dann entpackt ihr das oder entschlüsselt es. Und wenn ihr es nicht könnt, dann ist das kein Problem, weil irgendjemand irgendwann den Schlüssel rausbinden wird und dann könnt ihr es dann machen. Dann gibt es verschiedene Schritte, zum Beispiel den CPU rausfinden, die Load-Adressen und dann macht ihr eine statische Analyse über den Code und dynamische Analyse und dann sucht ihr nach Mustern, zum Beispiel in Strings oder Funktionsnamen oder Symbolnamen oder einfach nur Codeabschnitten. Und die Idee ist, dass man einfach hinter Türen oder die Bug-Informationen oder UART-Konsolen oder solche Sachen findet. Das kann man statisch tun, aber es kann man auch dynamisch tun, aber das ist ein bisschen schwieriger. Und wenn ihr keinen Gerät hattet, dann müsst ihr es kaufen. Manche machen es andersrum, die haben das Gerät, sie dampfen die Firmware und dann fangen sie so an, als hätten wir mit der Firmware angefangen. Aber grundsätzlich, wenn man die meisten Geräte analysieren will, dann will man nicht einfach nur nicht alle Geräte kaufen, nur um sie eventuell zu analysieren, sondern man will so billig wie möglich anfangen. Und das ist natürlich, indem man die Firmware kostenlos aus dem Internet bekommt. Und dann, wenn man, wenn man ein Grundstück der Annahme hat, dass die Firmware unsicher ist, dann kauft man das Gerät und richtet das ein mit den ganzen Kabeln und der Netzwerkkonfiguration und zum Schluss, wenn man noch tiefer gehen muss, das ist zum Beispiel bei manchen Verwutbarkeiten so, dass man physisch daran gehen muss, da muss man es auseinandernehmen. Es gibt also offensichtlich zwei Teile dieser manuellen Analyse. Und wir sehen, dass der Teil, in dem wir das Gerät kaufen und einrichten und auseinandernehmen, um an die U-Wart-Konsole zu kommen oder direkt an den Mikroprozessor oder den Flash-Speicher, dieser Teil ist schwer zu automatisieren, weil man nicht das Budget hat, so viele Geräte zu kaufen. Einfach nur auf den Verdacht, dass sie vielleicht unsicher sind und zweitens ist es nicht sehr einfach, diese ganzen Geräte gleichmäßig einzurichten. Es sei denn, man hat vielleicht einen wirklich klugen Roboter, das haben wir vielleicht in ein paar Jahren und es ist auch nicht sehr einfach, die Geräte automatisch auseinanderzunehmen und dass man dann automatisch sich mit dem Day-Tag verbindet. Es gibt Schritte, das zu tun mit beweglichen Teilen, die versuchen an den U-Wart zu kommen, wo dann Day-Tag, aber das ist immer noch hart, das ist immer noch schwierig. Auf der anderen Seite sehen wir, dass der erste Teil ziemlich einfach zu automatisieren ist. Denn die Firma zu bekommen, das ist nichts anderes als Download-Link zu suchen und vielleicht noch sich einzuloggen, wenn man ein Benutzernamen Passwort braucht, dann versuchen es zu entpacken. Bei einfachen Zips kann man das Brut forschen und dann macht man ein paar Heuristiken und dann sucht man nach Sachen, die man für die Analyse optimieren will. Es gibt natürlich ein paar Fallen, aber das hier als Prozess kann automatisiert werden. Von diesem Punkt an haben wir die Idee, eine Analyse im großen Stil zu haben, damit wir Firma-Images besser klassifizieren und analysieren können, ohne dass wir die Geräte dafür haben müssen, weil wir die Geräte in sich nicht brauchen, weil die meisten mit einigermaßen akzeptabelem Aufwand emuliert werden können. Es gibt ein paar Herausforderungen, z.B. die große Anzahl der Geräte, die große Anzahl der Firma-Dateien, das sind Herausforderungen, die wir lösen müssen. Und Internet of Things und eingebettete Geräte nutzen verschiedene Architekturen. Die bekanntesten sind ARM und MIPS und PowerPC, aber es gibt haufenweise andere Mikro-Präsistoren, von denen man nicht genau weiß, was sie sind und was sie tun und nicht alle benutzen Linux. Dann muss man rausfinden, was man mit dem Bytecode macht und so weiter. Und wir haben höchst unstrukturierte Firma-Daten, also auch wenn wir die aus dem Internet runterladen können, dann müssen wir trotzdem wissen, was was ist, weil wir ansonsten eine sehr ineffiziente, ineffiziente Blood-Forcing-Prozess haben. Und das können wir uns nicht erlauben, wenn wir so viele Daten haben. Und um diese Probleme zu lösen, schlagen wir eine Lösung vor, z.B. für die große Geräteanzahl, wollen wir einfach Gerätanalyse vermeiden, die große Anzahl der Firma-Dateien. Wir müssen viele Daten analysieren. Okay, das heißt, wir brauchen skalierbare Architekturen, weil diese Systeme sehr heterogen sind, brauchen wir eine Technik, die ausreichend generisch ist, die also nicht von der CPU-Architektur oder der Hardware-Architektur abhängt. Wir wollen so auf einer Zwischenebene sein oder Spezialtechnik haben. Dann gibt es einen Fokus auf Web- und Netzwerkoberflächen und APIs, weil alle diese Geräte, diese Netzwerkschnittstellen und APIs haben. Und insbesondere haben sie eine Web-Oberfläche, damit man die Geräte aus der Ferne verweiten kann. Hoch- und schrückte Firma-Daten, dem kann man entgegenkommen, indem man mit Maschinen-Learning die Firma klassiziert. Und da zeige ich euch gleich ein paar Beispiele. Zuerst also die erste Herausforderung, also die Klassifizierung der Firma und der Geräte. Warum ist das eine Herausforderung? Wir wissen auch wieder, dass es hunderttausende Firma-Pakete gibt. Und natürlich finde ich hier im Raum nicht viele Freiwillige, die von Hand sortieren wollten. Deswegen schlagen wir Maschinen-Learning vor. Und in unserem Fall nutzen wir Scikit-Learn, ein Python-Paket. Und die Idee hinter unserem Ansatz ist, wenn man Firma-Dateien hat, dann sind diese Dateien spezifisch für ein Gerät. Und wenn es ein Gerät gibt, dass eine bestimmte Anzahl an Megabyte für den Flaschspeicher hat, dann wird die Filmware-Datei mehr oder weniger 16 Megabyte haben, wenn es ein komplettes Update ist. Also da können wir ein paar Sachen machen, zum Beispiel die Dateientropie oder die Strings in den Dateien, anhand der wir schätzen können, zu welchem Gerät die Firma gehört. Und das sind die Eigenschaften, die wir benutzen. Also die Dateigröße, die Entropie, wie dicht die Strings in der Datei sind, wie viele einzigartige Strings in der Datei sind. Und dann versuchen wir die, als Features in dem Maschinen-Learning-Algorithmus zu benutzen. Und wir haben ein paar Sachen auseinandergenommen und rausgefunden, dass in unserem Fight der beste Ansatz der Random Forest war, mit größeren Entropie und Strings und einzigartigen Strings. Ich glaube, ich weiß, das sprengt ein bisschen den Rahmen dieser Präsentation. Aber das findet ihr in dem Forschungspaper, dass ihr am Ende der Folie empfindet. Die Grundidee ist, wenn wir ein anderes Feature haben, das nicht so gut ist, dann haben wir die Klassifizierung der Firma und da ist die Klassifizierung der Firma nicht sehr genau. In unserem Fall haben wir mehr als 90 Prozent Genauigkeit erreicht. Es hilft uns also, weil wir einfach sagen können, aus dieser großen Anzahl an Firmen, wie können wir in ein Hapien sortieren? Also wir haben Firmen von Anbiter A, Anbiter B, Anbiter C und können dann spezifische Entpackungstechniken oder spezifische Angriffsversuche benutzen, weil wir wissen, für welchen Anbiter die Firma gehört. Okay. Die Idee ist jetzt, dass wir, ich gebe euch jetzt mal die Demo, wenn wir euch am Ende der Präsentation zeigen. Die nächste Herausforderung ist, dass man die Statische Analyse auch automatisieren will. Wenn man eine große Anzahl an verschiedenen Firmen weiß hat, dann muss man die Analyse so schnell und so automatisiert wie möglich durchführen. Am Anfang haben wir uns überlegt, wir nehmen jetzt diese Dateien für die 100.000 Firmen weiß und packen sie in eine Datenbank. Dann haben wir eine Entpack- und Analyse-Routine geschrieben. Man kann das irgendwie auf seine eigenen Hardware laufen lassen oder zum Beispiel auch auf Amazon laufen lassen. Beliebige Anzahl an Knoten ist kein Problem. Wir haben dann Binwalk gewendet oder dieses Binary Analysis Toolkit, um das so entpacken und drüber zu laufen. Du kannst sie kombinieren oder ihr könnt auch was Eigenes schreiben. Wenn ihr Glück habt, funktioniert es einfach so. Wenn nicht, dann müsst ihr euren eigenen Entpack-Routine dafür schreiben. Ihr könnt es dann auch beliebig viele Knoten skalieren. Dann machen wir eine einfache Statische Analyse. Zum Beispiel sammeln wir Default-Wert, Password, da ungewöhnliche Password oder wir versuchen, ob da private Schlüssel für Zertifikate in der Firma drin sind, die nicht drin sein sollten. Dann speichern wir das ab in einer Datenbank, über die wir Reporting laufen lassen. Welche Analyse machen wir denn im Genauen? Wir suchen nach Web-Server-Konfigurationen. Wir machen da keine Statische Code-Analyse, weil es unser erster Versuch war und wir wussten nicht so genau, was wir erwarten können. Wir waren nicht so sicher, wie die Betriebssystemen verteilt sind, wie viele CPUs sich da finden, was davon Open Source ist. Wir hatten auch nicht die Software dafür, um das alles gleich abzufangen. Wir suchen nach Zugängen, ob die entweder schwach codiert sind, ob es Stiefholz gibt. Dann suchen wir noch Hashes in der ETC-Password und schauen, dass wir das matchen und suchen Strings in der Firma, die eventuell einen Eintrag im Hash sein kann in der ETC-Password. Dann suchen wir nach Versionen von den Software-Paketen, um herauszufinden, ob bestimmte Versionen von denen wir wissen, dass die bekannte Verwundbarkeiten haben, verwendet wurden. Aber wir wissen oft nicht, mit welchem Satz an Optionen die Bibliotheken kompiliert wurden oder ob sie noch gepatched wurden vom Hersteller. Insofern reicht das alleine nicht, weil es ist nie klar, ob die Anfälligkeit immer noch drin ist, wenn es ausgeliefert wurde oder ob es einfach schon ausgebaut wurde vom Hersteller. Das ist nie ein sicherer Treffer. Man muss immer noch nachschauen, ob es funktioniert. Wir haben auch Fuzzy-Hashes verwendet, um das Ganze dann irgendwie zu aggregieren. Wir schauen auf die Gemeinsamkeiten von verschiedenen Dateien, also nicht 1 zu 1 wie bei Krypto-Hashes, aber man kriegt schon eine Idee, dass eine gemeinsame Dateien mehreren verschiedenen Firmware-Paketen ist. Wenn da nur kleine Abänderungen sind zwischen den verschiedenen Dateien und verschiedenen Hersteller, dann kann man manchmal Anfälligkeiten für die mehrere Hersteller betreffen. Als Beispiel möchte ich euch jetzt ein Wi-Fi-Firmware zeigen. Die Chips haben diese Firmen im Bett. Das ist eine Verwundbarkeit, die bekannt war, die Cross-Site-Scripting betraf. Wir wissen, dass diese eine Firma anfällig dafür war. Dann haben wir Fuzzy-Hashing angewendet. Dann sehen wir, dass es einige andere Firmen 2, 3 und 4 gibt, die ähnliche Dateien hatten. Die haben wir dann versucht zu korrelieren mit dem Fuzzy-Hashing. Wenn dann eine bestimmte Datei anfällig war für Cross-Site-Scripting oder Remote-Code-Injection, dann war es möglich, dass die anderen ähnlichen Firmen es auch anfällig dafür waren. Also hier firmen wir 2 und 4 und die haben wir dann auch überprüft, ob die auch anfällig dafür waren. Manchmal hat man einfach den Fall, dass die Meere als einer von den Herstellern mit dem gleichen Bug betroffen sind, weil sie einfach das von einem Hersteller im Hintergrund kaufen und dann nur noch ihr Label drüberpacken. Was wir gefunden haben, was relativ interessant war, war, dass es HTTPS private Schlüssel für die Zertifikate gab. Dann haben wir uns gedacht, mein Gott, muss ja noch nicht ein Problem sein, wahrscheinlich erzeugen die einfach neu beim ersten Boot. Und dann haben wir in der Datenbank geguckt und beim Hersteller A dieses bestimmte Zertifikat gefunden, dass es ihm gehört und dass er auch noch eine Anfälligkeit hatten. Dann haben wir das über Siemer nachgeschauen. Dann haben wir festgestellt, dass Sie denselben Key verwendet haben. Dann haben wir die Fingerabdrücke, dieses IPv4-Adresse. Dann haben wir dann in einer Datenbank im Internet nachgeschaut. Dann haben wir festgestellt, dass es auch bei einem Hersteller B für die HTTPS-Verschüsselung benutzen. Die Schussbeugung ist, dass durchs Wahrscheinlich beide Anbieter von der gleichen Anfälligkeit betroffen sind. Das heißt, immer wenn man einen Explod findet, den bei A funktioniert, kann man ihn wahrscheinlich auch bei Hersteller B anwenden. Ich zeige euch das jetzt mal kurz. Das ist jetzt dieses konkrete Beispiel. Das ist eine SysTV-Kamera. Dieses konkrete S-Zertifikat wurde geknackt. Wenn man jetzt so eine Situation hat, wo das selbe Gerät von mehreren Herstellern verkauft wird unter verschiedenen Namen, dann sieht man nicht, wenn man das nicht als großes Ganze betrachtet, dann findet man einfach nicht, dass das selbe ist. Man schaut dann immer nur auf sein konkretes Barspiel und denkt, dass das geknackt werden kann, aber man verpasst die anderen. Wir haben uns dieses Britcom-Gerät nochmal angeschaut und man sieht, wir haben die Firma emolliert. Das ist sobald wir die Firma von Britcom A von dem Hersteller haben und die analysiert haben, dann können wir unter Umständen auch automatisierte Explods dafür finden, die dann wahrscheinlich auch bei Hersteller B funktionieren. Das ist jetzt ein automatisiertes, emolliertes System, dass die Firma von diesem SysTV-Hersteller laufen lässt. Wir schauen uns jetzt konkret Ihre Web-Interface an. Wir können jetzt auch dynamische Analyse darauf machen und nicht einfach nur SSL-Zertifikate automatisiert anschauen. Wir sehen, dass Ihr Web-Interface relativ schlecht funktioniert und wir haben auch schon den ersten Bug gefunden. Das ist jetzt das Interessante. Dann können wir jetzt Pen-Testing-Tools wie Erachne oder W3F oder was auch immer für kommerzielle Tools Ihr präferiert darauf laufen lassen. Könnt ihr jetzt versuchen, Remote-Code-Injections und Remote-Command-Injections auszuführen, was auch immer irgendwie was hergibt hier. In diesem speziellen Fall bei diesen Britcom-Kameras haben wir ein Zertifikat gefunden, bei dem wir eine Anfälligkeit gefunden haben, die relativ wichtig war und wir haben das dann mit zwei anderen Herstellern korreliert, sodass wir gleich 35.000 Geräten im Internet gefunden haben, die verwendet waren. Und wir haben insgesamt sogar 109 RSA-Schlüssel gefunden, mit denen HTTPS-Zertifikate aufgebaut wurden. Als erstes Ergebnis dieser relativ einfachen statischen Analyse, die wir durchgeführt haben, haben wir 38 neue Schwächen gefunden, Backdoors, Passwörter, die hinterlegt waren und wir haben das zugeordnet zu 693 Firmware-Images für verschiedene Geräte. Die letzte große Herausforderung, die wir hatten, ist die automatisierte dynamische Analyse, was ich euch gerade gezeigt habe, die von die emullierte Firma der Britcom-Geräte. Man hat am Ende relativ viele von den empackten Firmware-Dateien rumliegen und dann muss man irgendwie die Selektionskriterien auswählen, mit denen man da durchsieht. Man muss dann das Web-Interface in der Regel hochfahren, weil das das erste ist, was irgendwie im Internet hängt, sobald man das irgendwie ins Internet hängt. Und das ist üblicherweise das, was man sich ansehen will, um das Gerät aus der Ferne fernsteuern zu können. Und wenn es sich mit der Cloud verbindet, dann kann man sich da reinhängen. Wenn man jetzt in Haufen Firmware-Impact, dann wisst ihr schon, wie viel man da rumliegen hat. Am Schluss sind jedes Mal tausende Dateien und da kriegt man am Ende irgendwie ein Haufen falsch positive Treffer. Mülldateien, weil der Entpacker irgendwie beim Brutforzen zu sehr übertrieben hat oder weil einfach leicht andere Settings nötig gewesen wären, so wie bei JFFS2, da muss man aufpassen, ob man z.B. Big Indian oder Little Indian verwendet oder vielleicht haben sie auch einfach einen Bug, die Entpacker. Da braucht man ein paar Heuristiken, um rauszufinden, dass diese falsch positive Treffer eigentlich gar nicht da sind. Sonst wird es mit der Emulation hinterher schwierig. Und wir haben uns jetzt überlegt, wie man das skalieren kann. Es ist ein bisschen langsamer, weil man ja Emulation machen muss auf einem relativ langsamen Emulator. Und dann muss man ja auch noch Pen-Testing-Tools oder Fuzzer als dynamische Analyse-Tools ausführen. Und wenn wir diese dynamische Analyse dann ausführen, dann benutzen wir, wir benutzen dafür QEMO und wir sammeln die Resultate für Maschinen-Learning. Aber das manche mal schreckt, dass es fehlen, vielleicht gab es einen Problem in Kernel, oder es fehlen uns Module. Und das passiert ganz schön oft, weil nicht alle Firma-Pakete vollständig sind. Die meisten Firma-Updates sind nur Teil-Updates. Also meistens bekommt man einfach nur ein Diff oder die Betroffenen der Teilen. Die Hersteller schicken ja nicht jedes Mal das komplette Teilsystem. Und deswegen musst du wissen, warum die Emulation oder die Analyse fehlschlägt. Aber das Schwierige ist jetzt, wie emuliert man heterogene Architektur so, dass es skaliert? Oder wie macht man das überhaupt? Macht das Spaß, aber nach einem halben Tag nicht mehr so sehr. Und wir müssen einen Emulator aussuchen. Es gibt viele Optionen dafür. Der ideale Emulator ist, den gibt es einfach nicht, ein idealer Emulator, den würde man einfach eine Datei geben und er würde automatisch die Architektur wissen, würde die CPU kennen, das Betriebssystem und wüsste, wie man das putten muss und wie man die ganzen Dateien lädt. Aber soweit wir wissen, gibt es sowas nicht. Zumindest nicht öffentlich. Dann gibt es generische Systeme, Emulator, zum Beispiel QEMU. Und da gibt es zwei Optionen. Man kann es benutzen mit der Original-Firmware und dem Original-Körnel oder mit der Original-Firmware und einem generischen Kernel-Körnel. Aber das Problem ist, dass die meiste Firmware nicht mit einem Kernel-Update kommt. Das meiste ist einfach Kernel 2.6 von vor zehn Jahren. Das heißt, die Kernel-Updates gibt es nicht häufig und schon gar nicht in Firmware-Updates. Deswegen muss man es entweder mit JTAG extrahieren oder mit einem manuellen Prozess, der wieder nicht skaliert. Und in diesem Fall der generische Ansatz mit generischen Optionen wäre eine bessere Idee. Und dann gibt es andere Optionen. Zum Beispiel kann man die Anwendung, die man testen will, nehmen und sie aber nicht in einem Emulator testen, sondern in einer Testumgebung, die sich von der emulated Umgebung entscheidet. Das funktioniert sehr gut für interpretierte Sprachen, zum Beispiel PAP oder Pearl, wo es eine Virtualisierungs-Umgebung gibt, die man dann nachschlagen kann, ohne dass man den ganzen QEMO-Krempel braucht. Und wir mussten ein paar Entscheidungen treffen, den perfekten Emulator gibt es nicht, den können wir also nicht benutzen. Die meiste Firmware enthält keine Kernel, das heißt, das können wir auch nicht benutzen. Und das hier war zu experimentell. Also das steht im Paper, aber ich werde euch hier nicht damit langweilen, aber ihr könnt es gerne selber nachschlagen. Das heißt, wir haben diese zwei Ansätze benutzt, also die Original-Firmware mit einem generischen Kernel und in dem Fall, wo man den Gust der wegwerfen kann und einfach den PAP oder Pearl-Teil benutzen kann und dann in ein X86-Testumgebung werfen kann und unter einem Patch laufen lassen kann, dann haben wir das gemacht. Die Idee ist, dass ihr QEMO habt. Das läuft in einem normalen Gerät oder in einer virtuellen Maschine, in unserem Fall in einer VM. Das machen wir unter Debian, das sind technische Details. Und dann sehen wir, und dann haben wir den CH-Route. Das ist die Prozedur, in der ihr das Wurzeldetail-System von dem Data-System unter dem ihr arbeitet ändert. Und ihr könnt QEMO sagen, von jetzt an ist das, ist die Wurzel unserer Firma-Dateien, unsere Wurzel-Dateignoten. Und so kann man relativ leicht emulieren. Es gibt auch hier wieder Fallstricke, aber für die meiste Firma funktioniert das sehr gut. Und weil man in einer CH-Route-Empgebung ist, dann kann man einfach das normale Linux verwenden und das laufen lassen. Natürlich wird man dies auf der Tee schlagen, weil QEMO kein Gerät hängt, weil man ein paar Sachen, ein paar Plug-in schreiben muss, damit man den Flaschspeicher emulieren kann, das ist ein Stereo-Port, Ethernet. Zum Glück ist die Netzwerkschnittstelle in QEMO relativ gut gemacht, aber für andere Sachen muss man häufig eine gute Plug-in-Bibliothek schreiben, die für die meisten Geräte funktionieren würde. Und sobald man das hat, kann man diese Probleme umgehen. Und dann startet so ein Web-Server, das ist zum Beispiel Light HDBD oder was auch immer. Das kann aber auch ein alleinstehender Binädeteil sein. Und dann bist du nur in diesem Web-Server-Teil interessiert. Und dann nehmen wir einfach nur Arachnisab W3AF Pentesting-Werkzeuge. Wir haben den CP-Dump genommen, um rausfinden zu können, welche Eingaben einen bestimmten Crash-Trigger oder eine bestimmte Command-Injection, eine bestimmte Schwachstelle. Man kann Nmap oder Metasploit usw. verwenden und dein komplettes Werkzeug also nahe darauf feuern und rausfinden, was funktioniert. In unserem Fall haben wir die Web-Schnittstelle genommen und deswegen haben wir diese Werkzeuge genommen. Und als Ergebnis hatten wir ungefähr 225 hochkritische Schwachstellen, zum Beispiel Command-Injection, Cross-Sites-Grouping und CSRF. Und diese Schwachstellen betreffen 25% der Hersteller. Aber dieses Framework haben wir nicht entwickelt, um alle Schwachstellen zu finden. Aber wenn man dieses Framework hat, kann man die niedrig hängenden Früchte sehr, sehr schnell finden. Und als Hersteller auf einmal ein Zehntel seiner Schwachstellen zu finden oder als Pentester kann man, wenn man diese Sachen schnell finden, man will ja nicht seine ganze Zeit damit verbringen, die Sachen von Hand zu suchen, sondern du kannst es einfach über Nacht laufen lassen und am nächsten Morgen hast du 225 Schwachstellen gefunden. Ich habe euch ein Teil dieser Demotion gezeigt, also das ist diese Brick-Com-Kamera. Man kann damit ein paar Sachen rumspielen, aber ich wollte euch zeigen, wie der Prozess aussieht, wo man mit der Firma anfängt und zur Korrelation kommt und dann die interessanten Dinge findet. Wenn ihr also die Analyse dieser Dateien gemacht habt, dann könnt ihr die nach Strings korrelieren und werdet sehen, dass manche der Firmwares, insbesondere HP, dass sie Firmware aus dem Internet wieder rausgeholt haben, die diesen Fehler enthalten haben. Also ich konnte den Backdoor-Kanal nicht öffnen. Es hört sich nicht Spaß an. Also wenn ihr nach Schlüsselwörtern besucht, dann werde ich hier überrascht sein, wie viele davon, zum Beispiel das Backdoor enthalten. Also manche davon sind, also mit manchen findet man tatsächlich echte Hintertüren, indem ihr einfach nach dem Wort Backdoor sucht. Also Sie wissen aber, dass das ziemlich offensichtlich ist, wenn ihr die Geschichte von Juniper kennt, dann haben Sie Kryptogramme benutzt, aber wenn ihr diese Art von Kryptogrammen habt, dann könnt ihr auch nach diesen Kryptogrammen suchen und dann findet ihr hier diese Firmware und seht diese Details und von da aus weitermachen. Ihr könnt auch nach bestimmten Schlüsseln suchen, ob die hier in dieser oder jener Firmware enthalten sind, aber damit ihr diese Fuzzy-Hash-Sache versteht, wie ich euch schon auf den Foden gezeigt habe, irgendwo hier. Das ist der Fuzzy-Hash, wo ich mit SD-Karten und der Detail-Korrelation gesprochen habe. Wir wissen, dass diese Datei verwundbar ist auf einer dieser SD-Karten. Das war ein sehr bekannter Blockpost. Und wir können auch einen Fuzzy-Hash suchen und finden raus, dass diese Datei in diesen Firmware enthalten ist. Einigen davon. Es ist jetzt nichts Besonderes, weil die einfach inkrementelle Version derselben Gerätefirma ist. Und wir können sehen, dass die Ähnlichkeit 100% ist. Das heißt, diese Datei hat sich in den Versionen nicht geändert. Aber das Interessante ist, dass manche dieser Einträge, dass sich in manchen dieser Einträgen der Hersteller geändert hat. Und das kann man leicht einstellen, dass man, wenn eine Datei bei unterschiedlichen Herstellern ist, dann weißt du, dass irgendwas merkwürdig ist. Dann muss der andere Hersteller auch verwundbar sein. Und die Ähnlichkeit ist nicht 100%, sondern 46%. Das liegt daran, dass diese Hersteller ihre White Labels oder ihre Entwicklungskits nehmen und dann einfach ihr eigenes Logo drauf tun oder einen eigenen Copyright Text. Also, es ändert sich die Dateien. Aber die Kernfunktionität ist die gleiche. Also, die ändern einfach nur ihr Copyright. Aber der Web-Server zum Beispiel ist derselbe. Also, es ist die Ähnlichkeit nicht 100%, aber es ist immer noch da. Also, das hier ist zum Beispiel PQIR. Das ist Version 1, 46, 47. Aber soweit man dieses Wissen hat, dass diese Datei verwundbar ist und zwar Hersteller hat, dann kann man einfach beide davon emulieren und schauen, ob sie verwundbar sind. Und in einem Fall seht ihr, es ist die selbe IP, es ist die selbe virtuelle Maschine, es ist Transcend-WiFi-SD. Ich kann das so killen. Und ich mache hier wieder eine andere Klammer auf. Aber wenn man diese Emulation hat, dann kann man sehr schnell Bugs finden, wie zum Beispiel unberechtigten Zugriff. Also, hier fragt es mir nach einem Passwort. Aber wenn ich auf diese Unterseite gehe, dann sagt es, oh ja, hallo. Also, das ist wirklich nicht sehr klug. Also, man kann diese Verwundbarkeiten leicht finden und das generiert hier jede Minute ein Verwundbarkeit. Also, wir können uns einloggen. Manchmal sind die Interfaces kaputt. Also, ihr seht zum Beispiel, hier ist keine MAC-Adresse, weil es irgendwelchen internen Code-Aufruf, der QEMO nicht unterstützt und dafür müsste man ein Pluck inschreiben. Aber die Idee ist, dass man immer noch Verwundbarkeiten finden kann. Zum Beispiel, wenn ihr hier ist der Arachanename. Das ist wie daran, dass jetzt Arachni diese Maschine pentestet. Also, es hat einfach ein Pentest ausgeführt auf dieser Maschine und jetzt will ich es noch schnell von Hand ändern. Also, man sieht, wenn man jetzt den Emulator verwendet, muss man nicht dieses 40, 50 Euro Gerät kaufen. Wir haben jetzt dieselbe Command-Injection gefunden und automatischisiert ist es einfach viel leichter zu finden, so was. Das ist jetzt der PQIR und wir gehen jetzt auf das Wi-Fi-Setup. Wir versuchen jetzt einfach mal dasselbe zu machen. Also, es ist im Prinzip dieselbe, seitdem Hintergrund der Output schaut, einfach ein bisschen anders aus. Deswegen ist auch die Ähnlichkeit nicht 100%, aber wenn man sich jetzt die QEMO anschaut, man sieht hier, da ist dieses K-Card überall im Code zu finden und da sieht man schon, wie ähnlich das ist. Man sieht, dass es im Prinzip dieselbe. Man hat quasi dieselbe Schwachstelle in verschiedenen Herstellern gefunden. Einfach nur das Toolset anstoßen und am Schluss hat es alles für dich erledigt und du kannst es dann auch einfach verwenden. Das ist im Prinzip schon alles. Deswegen möchte ich jetzt auch abschließen. Dann haben wir noch ein paar Minuten zum Fragen stellen. Aber ich sage euch, es gibt einen Haufen Schlaf, also Schwachstellen in Embedded Devices, die noch darauf warten gefunden zu werden und im Prinzip, wir sehen immer wieder, wenn Sie ein Update machen, dass Sie zehn Jahre alte Pussybox und Linux Kernel-Versionen ausliefern. Firmware, Sicherheitsanalyse ist echt wichtig, weil wir sehen jeden Tag Probleme, wenn zum Beispiel ein Juniper Backdoor-Problem bekannt wird, dann stürzen sich sofort alle drauf und analysieren das auch. Wir sind uns eigentlich einig, dass das total wichtig ist, die Firmware zu analysieren. Aber man muss es deutlich weiter sehen. Einfach, weil dieselbe Schwachstelle oft nicht nur bei einem Anwender, bei einem Hersteller zu finden ist, wir finden dies dann auch bei vielen anderen. Das ist zum Beispiel dann nicht nur ein Juniper OS, das betroffen ist durch eine Crosshairscript-Schwachstelle, sondern auch andere. Aber klar, es sind natürlich viele nicht triviale Schritte dabei und diese Probleme muss man lösen. Manchmal haben wir ein bisschen abgekürzt und haben sicher nicht 100% Resultate gehabt, dass wir alles gefunden haben. Aber es ist auf jeden Fall besser als nichts und wir sehen das für viele Hersteller, vor allem die Noname-Produkte, also die großen Hersteller, die diese Noname-Produkte kaufen und dann ihr Label drauf packen, einfach Sicherheit, überhaupt keine Priorität ist, weil die Zeit ist zu entwickeln und die Kosten für sie das Wichtigste ist und deswegen ignorieren sie die Sicherheit völlig. Also das hier sind meine Quellen. Bitte lest sie, teilt sie, zitiert sie oder gibt mir Feedback oder stellt mir Fragen, Rat, Ideen. Ich freue mich über Feedback. Ich bleibe auch noch eine Weile hier oder benutze meine E-Mail. Ich möchte jetzt noch meinen Kollegen danken, mit denen ich Teile dieser Forschung gemacht habe. Jonas Sallach. Danke. Wenn ihr noch Fragen habt, dann fragt. Danke. Danke für den großartigen Vortrag und wir haben jetzt noch 10 Minuten für Fragen, aber wenn ihr wirklich gehen müsst, dann macht das bitte so leise wie möglich. Also es geht einfach zu einem der Mikrofone, links oder rechts und stellt auch Fragen. Danke bei dem Mikrofon zu meiner Rechten, bitte. Danke für den tollen Vortrag. Ich habe mich gefragt, weil ihr die Geräte nicht immer kauft und die exploits nicht immer auf den Geräten selber testet, ob ihr Probleme dabei habt, die Hersteller dazu zu bringen, dass sie diese Verwundbarkeiten anerkennen, die nicht auf dem echten Gerät getestet wurden. Tatsache, dass wir nicht immer die Geräte kaufen und auf den echten Geräten testen. Also die Idee war, dass man eigentlich ein paar Zero-Day-Attacken auf Rotern finden und die Hersteller haben dann auch wirklich angefangen zuzuhören und deswegen können wir die jetzt noch nicht veröffentlichen. Also ja, die Hersteller, die haben die Verwundbarkeiten, die haben die Verwundbarkeiten, also ja, die Hersteller fangen wirklich an und schauen sich die Ergebnisse an, auch wenn wir nicht auf den echten Geräten getestet haben. Wir geben ihnen möglichst viele Details, wie wir das gefunden haben und was für Imports wir gegeben haben, um das auszulösen und was unsere Methodik dafür ist, um das zu finden. Wir versuchen, Verantwortung zu zeigen und das vernünftig zu reporten. Also ja, um das zu bestätigen, die Hersteller schauen sich das wirklich an und als Miss in unserem Fall, es ist gut. So haben sie keine Zero-Day-Attacken und sie haben Zeit, das noch zu lösen. Glückwunsch zu dem tollen Vortrag. Wann hast du QEMO-Geräte geschrieben und willst du sie öffentlich machen? Gute Frage. Ich bin kein besonders QEMO-Affiner-Typ, aber mein Kollege, Mr. Sardach, der ist ein QEMO-Experte und der arbeitet an binärdynamischer Analyse und er schreibt diese Plugins, um das zu mappen. Ich würde dir empfehlen, nimm doch mal Kontakt mit dem auf und wenn du Fragen oder Vorschläge hast, in unserer Methodik haben wir im Prinzip das Standard QEMO verwendet. Aber wenn wir so eine Bibliothek an Geräten für die Device ist zu haben, dann ist es total simpel, die da mit rein zu packen und dann noch mehr Angriffsfähil zu finden. Das Internet fragt, sind alle Features, die du gezeigt hast in Filmware vorhanden und ist die Open Source, ist die Quatex herunterladen da? Die ganzen Filmware-Daten sind viele Teile der Firmenware können wir mit anderen Leuten teilen, aber wegen Copyright können wir nicht einfach die Firmenware selber weiterverbreiten. Aber wenn wir das irgendwie auf eine Seite packen würden, dann würden wir das illegal weiterverbreiten und das darf ich natürlich nicht und das ist ein bisschen tricky. Aber wenn jemand einen spezifischen Test auf Daten, die wir haben, laufen lassen will, dann schreibt uns einfach eine Mail und dann können wir euch vielleicht Zugriff drauf geben oder ihr schickt uns ein Skript und wir führen das aus und das war jetzt die erste Frage und die zweite ist, das Projekt war nicht so gedacht als Open Source. Wir wollen das eher als Service laufen lassen, so dass wir der Community so viel zurückgeben können an Informationen wie wir können, aber auf derselben Zeit selber noch Änderungen dran machen können und es ist auch nicht wahnsinnig schwierig, wir beschreiben das alles in den Paper. Es ist im Prinzip nur Jobverteilung und wir geben auch mal Commits irgendwie verschiedene Projekte, die wir verwenden, also binary toolkits oder so weiter und ja, wir sind mit der Open Source Community verbandelt aber. Danke für den tollen Vortrag. Ich habe zwei Fragen und die erste kurze Frage ist, wie lange braucht ihr für die dynamische Analyse der Firma, um Schwachstein zu finden? Um das zu emulieren? Ja, wir müssen da schon irgendwie gewisse Maßnahmen der Vorsicht zu ergreifen, einfach um sicherzustellen, dass das Setup einigermaßen funktioniert und wir können keine konsistente Zeit sicherstellen, wenn es in QEMO läuft, weil die Hardware ist ja auch verschiedene, die wir emulieren, aber im Allgemeinen kann man sagen, die Zeit, bis von QEMO start, bis es oben ist, bis zu fünf Minuten, kommt darauf an, was es laden muss und ob es alle Geräte hat und ob dabei sich Fehler ergeben. Und für das Pan Testing, da kommt es ein bisschen drauf an, was für dynamische Analyse man laufen lassen möchte. Also XSS, CSRF, Command Injection oder so, diese Module bei Erachne, die brauchen schon ein bisschen länger, wenn wir sie laufen. Also die machen schon so 10.000, 20.000, verschiedene Inputs pro Klasse. Das braucht schon eine halbe Stunde, Stunde oder so, um das zu testen. Oh, ich glaube, wir sollten diejenigen warten, die dort warten, für einen langen Zeit. Okay, erstmal vielen Dank für das schöne Gespräch. Danke für den tollen Vortrag. Ich habe eine von meinen vielen Fragen ausgewählt, die dich wahrscheinlich am meisten interessiert. Wie würdest du den Firmware-Teil skalieren? Von einem der Folien habe ich den Eindruck gehalten, dass deine momentane Stichprobe 2000 Firmware-Images sind. Aber wie willst du die ganze Firmware von anderen Browser-Seiten laden und bearbeiten? Also die sind ja nicht öffentlich. Das heißt, man sieht so aus, als müsste man danach googeln und das dann von Hand runter laden. Wie groß ist überhaupt deine Stichprobe gerade? Unsere Stichprobe-Moment hat, also das Sample, das wir für die erste Untersuchung verwendet haben, waren so 170.000 verschiedene Images, die wir angeschaut haben. Die haben wir mit Google-Suchen und FDP-Spider runtergeladen und davon haben wir dann irgendwie einfach erstmal ein Seat genommen, irgendwie ein kleiner Anzahl an Hersteller und sind von da aus dann weitergegangen. Und am Schluss waren es dann wirklich 170.000 Firmware-Files und dann haben wir die statische Analyse auf ungefähr 30.000 ausgepackten Dateien durchgeführt und das lag einfach nur an akademischen Gründen. Wir hatten einfach nicht die Zeit und dann haben wir die statische und dynamische Analyse drüber laufen lassen wollen, aber es hat relativ lange gedauert, weil das Pen-Testing das dauert doch etwas und wir haben dann einfach das nur auf 2.000 laufen lassen. Das ist so, wie sich die Samplegrößen auf die verschiedenen Stages aufteilen. Natürlich gibt es immer irgendwie Dateien, irgendwie hinter, also die man nur als Kunde runterladen kann, die quasi hinter einer Passwordabfrage fest gesichert sind. Und wir überlegen uns, dass wir auch in Zukunft Machine Learning drauflaufen lassen, um nicht nur die Dateien zu verwenden, die wir haben, sondern auch die, die man so noch finden kann. Und das waren ungefähr 10 Geber in Daten, in diesen 2000, in diesen 2000, die wir angeschaut, also ungefähr 10 MB pro Datei. Danke, leider haben wir keine Zeit mehr, deswegen können wir keine weiteren Fragen annehmen.