 Fragen zu dem Vortrag haben, stellen Sie sich bitte an die Mikrofone. Hallo, dieser Kongress ist wirklich etwas Tolles. Das war jetzt der erste Kongress, den ich in diesem Zentrum hatte. Wir sind beides Forscher von der TU München. Und wir machen Viertel-Maschinen-Introspection. Das ist das Thema, mit dem wir uns jetzt die letzten drei Jahre beschäftigt haben. Kurz zu sagen, worum geht es in diesem Vortrag? Was ist unsere Motivation? Was ist die Technik, mit die wir hier beschreiben möchten? Wir werden über zehn Geburtsrechellen. Wir werden drei Techniken erwähnen, die wir anwenden können. Und nachdem wir die Grundlagen angewendet haben, werden wir dann auch zu unseren Ergebnissen kommen. Was das für Probleme bereitet. Wir werden diese Teil der Integrität und Körner-Sicherheit aufteilen. Zuerst mal schauen wir uns die Schadzoffeer-Sammlungen und Schadzoffeer-Analyse an. Wie das bei Viertel-Maschinen beschrieben kann. Wir behandeln auch die Eindringen, die das Entdecken von Eindringen geschehen kann. Und wie man es verhindern kann. Und wir werden auch ein Produktestyp zeigen, den wir entweder haben. Und auch etwas über die Barging, ganz besonders Verbeugendes, die Barging von Viertel-Maschinen erzählen. Natürlich ist Cloud Security ein sehr wichtiger Teil davon. Aber auch die Sicherheit mobiler Anwendungen ist wichtig, zum Beispiel von Handys oder sonstigen mobilen Geräten, wie man die vom Malwehr schützen kann. Worum es uns nicht geht, ist Digital-Rage-Management oder Man-in-the-Middle-Attacken auch keine Spiellage oder auch keine geheimen Mut gibt. Wir haben Skil über Hacking gehört auf Deepen-Kongress, aber dieser Vortrag geht nicht darum. Wir haben Viertel-Maschinen, und wir müssen irgendwie schauen, was die Digital-Maschinen geschieht und irgendwie kontrollieren, was da passiert. Zu Baschinen hat man Vox oder VM-Ware oder Zen. Die sind relativ einfach zu implementieren und angenehm. Man kann mit den Speicher-Teilen oder das Netzwerk mit anderen Servern außerhalb der VMs zu kommunizieren. Man kann auch Netzwerk-Monitore verwenden, z.B. Snort oder TCP-Mon. Die haben allerdings keinerlei Isolation, da sie in der VM rauf. Andere Sachen haben ihm eine Isolation, weil sie außerhalb der Vorträten Maschinen laufen und somit besser geschützt sind vor Auswirkungen in der VM. Allerdings verliert man dadurch den Kontext und man weiß nicht zurecht, was eigentlich individuelle Maschinen passiert. Es gibt auch Möglichkeiten für eine Live-Verwendung, wo man z.B. den Speicher oder die Festartestcannen kann. Da haben wir zwar eine gute Isolation und auch den Kontext, aber es ist eine passive Sichtweise. Es gibt also Vorflachteile jeweils. Da kommt nun Virtual-Maschine, Introspection ins Spiel. Wir schauen z.B. die virtuelle Hardware an und müssen irgendwie rekonstruieren, wie der Zustand der Virtual-Maschine ist. Das ist ein ähnliches Konzept wie z.B. die Packet-Inspection. Da möchten wir auch versuchen zu rekonstruieren, was im Betriebssystem passiert. Wir müssen also wissen, welches Betriebssystem individuelle Maschine läuft um zu verstehen, was dort passiert, wie z.B. die Pakete segmentiert sind und so weiter. Wir möchten auf jeden Fall eine Isolation erreichen, um eine höhere Widerstandsfähigkeit zu bewirken. Damit haben wir dann eine höhere Sichtweise auf das System und da wird in einem privilegierten Zustand das System sind. Wir können diese Dinge besser betrachten. Zuerst mal Isolation. Da bewegen wir die Prüfung außerhalb der Virtual-Maschine, denn wenn wir den Code außerhalb laufen lassen, können wir Hux im Gasbetriebssystem vermeiden. Und somit kann in der Virtual-Maschine nichts falsch laufen. Manipulationen sind natürlich dann schwieriger, denn die Isolation erfolgt durch den Hypervisor und es ist natürlich schwierig, aus der Virtual-Maschine auszubrechen. Der Hypervisor ist meist sicher, und wenn die Hardware gut ist, dann können wir den Code auch viel mehr vertrauen, weil er sich in einem geschützten Bereich erreicht. Außerdem haben wir dadurch eine Performance gewinnt, weil wir keinen sogenannten Antivirus-Sturm haben, den wir in jeder Maschine dann hätten. Auf diese Art und Weise können wir vermeiden, dass alle Antivir-Scans mit allen Maschinen zur gleichen Zeit aktiv werden. Wir übertieren dann, was passiert mit den Maschinen, dass die Maschinen in jeder Maschine sehr kritisch sind. Es ist natürlich erst mal schwierig, die virtuelle Hardware zu verstehen. Da liegt der Fokus Christen Teils auf dem Speicher. Das hängt Christen Teils zu der harte des Systemes ab, auch natürlich vom Zugriff auf die CDU-Registe, auf Netzwerke und Festblattenscans. Und so können wir dann den Speicherzustand rekonstruieren. Das ist allerdings sehr schwierig und sehr fehleranfällig, wegen der hohen Komplexität. Und der ist meistens Windows drauf oder Windows unter. Natürlich ist das im Fall von Windows einige Schwierigkeiten, denn wir haben kein Zugriff auf dem Quailcode und wissen so, wie viele die nicht bescheiden. Also, wenn die Maschine außerhalb der Virtuellen Maschine läuft, haben wir natürlich das Dilemma, welchen Daten wir überhaupt vertrauen können. Aber gehen wir mal zum Abstand zurück. Wenn wir uns anschauen, wie der Speicher aufgebaut ist, haben wir natürlich den Physikalischen Speicher beim Virtuellen Maschinen in der Sprache. Das ist Virtual Paging und Virtueller Speicher. Das ist das, was schon seit geraumer Zeit existiert. Die Hardware geht diese ganzen Paging-Tabellen durch, wenn sie Speicher benutzt. Und das Interface zwischen der Hardware und der Software ist so, dass die Software sagt, was sie möchte und die Hardware geht dann zum Entschwingen-Speicher. Wir haben verschiedene Paging-Systeme und zwei Extensions zu das. Und dann haben wir das 64-Bit Paging. Und wir haben verschiedene Erweiterungen dazu. Es wird dann teilweise emulliert, was die Hardware tun würde. Es gibt hier zum Beispiel drei Bits, die jeweils vom Betriebssystem anders verwendet werden. Zum Beispiel Windows, wir haben zwei Bits davon, unterschiedlich, je nachdem, welches Betriebssystem läuft und davon hängt dann ab, wie diese Paging-Tabellen ausschauen und was wir dann aus dem Speicher zurückbekommen. Wenn dann ein Translation der Speicherbereiche stattfindet, dann wird zum Beispiel das 11-Bit gesetzt und das 10-Bit nicht gesetzt. Dann ist zum Beispiel diese Page vorhanden. Das wird zum Beispiel auch bei Linux ausgesetzt, auch wenn es dort vielleicht nicht so richtig ist. Es ist also schwierig, je nachdem, ob wir Windows oder Linux anschauen, und es zeigt, dass eine präzise Rekonstruktion des Speicherzustands sehr komplex ist. Es gibt natürlich auch andere Probleme, mit dem Speicher zum Beispiel, wenn man sich das Speicher ausgelagert wird, und wir keinen direkten Zugriff haben, aber wir haben natürlich Zugriff auf die virtuelle Disks und können es so wiederum auf das Swap-File zugreifen. Dann können wir wieder schauen, wie das Betriebssystem das Swapping implementiert, was natürlich wieder zusätzliche Komplexität mit sich bringt. Wir schauen erst mal, wie man zum Beispiel Page-Page-Page-Tabellen, über den Hyper-Weißer in die VM bringen kann. Das braucht natürlich eine gewisse Zeit, denn das Betriebssystem muss das alles ausführen, und das dauert natürlich eine gewisse Zeit, aber wir machen Fortschritte. Ein Problem ist zum Beispiel, dass wir erst mal die Page-Tabels finden müssen. Ein Problem ist zum Beispiel, dass wir erst mal die Page-Tabels finden müssen. Ein Möglichkeit ist zum Beispiel, dass die Tools eine gewisse Signatur schreiben, die sie dann suchen. Wir haben hier ein kleines Code-Signal, es sind hier vier Bytes, das ist die Signatur, um die Page-Tabels zu suchen. Das ist jetzt nur ein Teil eines Headers, nämlich des Headers eines Prozesses, der beim Bespeichern kommt. Wir haben aber auch Zugriff auf die Prozessoregister und können diese auslesen und können diese dann benutzen, um die Translation durchzusuchen. Das hat natürlich einen gewissen Vorteil über ganz grundlegende Speicherzugriff. Wir müssen natürlich den Kernel verstehen und rekonstruieren, was der Kernel sehen würde und das dem Debug nachfragen. Microsoft gibt diese Debugging-Informationen zwar heraus, aber es ist ein propreteres Format, aber das würde zum Glück schon reverse-engineered und in JSON-Tabels gedammt von Recall, was ein Teil von Google ist. Und wir können diese Debugging-Information natürlich nehmen. Bei Microsoft ist das jetzt also inzwischen ganz nett. Bei Microsoft ist es alles ein bisschen problematisch, denn wir haben Kernels, die sich je nach Distribution unterscheiden. Zum Beispiel bei Ubuntu haben wir kein einheitliches Repository, wo man diese Informationen wer bekommt. Es kann sein, dass sie ihre eigenen Informationen haben oder für alte Distros ist sie schon wieder verschwunden aus dem Netz. Insofern ist bei Microsoft das Ganze natürlich schöner, weil sie zumindest ein zentrales Repository haben. Wir haben aber auch zum Beispiel Fedora Dark Server, wo wir ein zentrales Repository haben und das ist zumindest schon mal ein Schritt in die richtige Richtung. Es gibt aber zumindest ein paar Initiativen in diesem Bereich. Wir gehen zurück zum Scanning. Wenn man jetzt ein Debugging... Wir wollen, wie die Daten finden, die in die wir interessiert sind. Und dann finden wir zuerst den Kernel und dann finden wir die Prozesse und dann sucht man, was man sonst noch finden will. Und in Windows suchen wir dann für PoolTagHeaders. Und da ist der Debuggerheader angebracht an den... Und ähnlich wie für den Scan, den wir vorher gesehen haben, sind das noch mal so vier Beizignatoren, die wir suchen können. Aber das Problem damit ist, dass wir davon eine Menge haben und dass wir nicht wissen, was davon Valide ist und was nicht. Also man hat Teilstrukturen in Speicher und dann hat man ganze Strukturen in Speicher. Und man weiß nicht... Und man muss dann für vier Charakteren die Buchstaben suchen. Man hat davon eine Menge. Man muss es finden und das Betriebssystem tut so, als wäre es nicht mehr da, aber es ist immer noch da und man kann es natürlich finden. Und jetzt weiß man nicht, welche Daten Valide sind und welche nicht Valide sind und natürlich noch viel schwer. Und natürlich haben Leute entdeckt, dass das problematisch ist. Und 2012 gab es dann ein Paper bei One Wide Modification von Breaking Memory for Reference. Und es gab noch ein Paper und es gab noch ein Paper, das darüber gesprochen hat, ganz viele andere falsche Intrusions zu adden und dann kann man wirklich nicht sagen, welches falsch und welches richtig ist und es ist problematisch. Und wir wissen nicht wirklich, welche Daten wir vertrauen können und welche Datenstrukturen Valide sind und welche nicht für durch die Scans. Und jetzt bekommt er die Interposition, wird kritisch. Denn wir suchen jetzt einfach eine ganz spezifische Position, denn wir wissen, wo das System ist und dann können wir Teile vom Scanned Avoid und wir können mit diesen Methoden eine Kernel finden und weitere Debugmethoden verwenden, um den Heap zu finden und dann haben wir natürlich eine komplette Speicherabdeutung. Das sind schon ähnliche Teile, die wir in der Verkaufung haben. Das sind schon ähnliche Teile die wir vorhin benutzt haben. So können wir gewisse Dinge auf dem Heap finden. Es ist zum Beispiel, dass wir einen nativen Support in Scanned eingebaut haben. So können wir also den Hypervisor verwenden, egal was verwendet wird. Allerdings ist das noch relativ unbekannt und es gibt noch undokumentierte Features dabei. Wir brauchen also Beispielcode oder wo es im Sourcecode versteckt ist, um darüber etwas zu lernen. Schauen wir uns mal an, wie so etwas funktioniert. So, hier laufen jetzt zwar auf IAMS, zum Beispiel Windows 7 und also Windows 7. Also, zum Beispiel Windows 7 und noch etwas anderes. Wir können jetzt alle Prozesse auflisten, die in Windows System laufen. Das ist relativ ähnlich zu den Forensik-Tools. Das funktioniert und wir sehen zum Beispiel, dass mehr Prozesse laufen als uns der Task-Mensch eigentlich anzeigt. Es gibt Kernel-Module die man sieht. Zum Beispiel Kernel.exe Wir können also herausfinden, was in Spanien geladen ist. Das sind alles die Kernel-Internen-Datenstrukturen die hier verwendet werden. Das ist zum Beispiel eine Live-Ausführung des Windows-Kernels. Hier sehen wir alle internen Systemfunktionen die von Systemcode ausgeführt werden. Das sind die ganzen Funktionen die von Systemcode aufgeführt werden. Es wird geschieht ein Haufen, auch wenn wir Windows überhaupt gestohlen. Wir sind nicht in der Lage zu sehen, was überhaupt passiert. Das sind die ganzen Funktionen, die aufgerufen werden. Wann jetzt gerade überhaupt nichts. Und es ist immer ein Haufen los. Aber es ist verdeutlicht, dass wir in der Lage sind wie die Ausführung des Systems hineinzuschauen und auszufinden, was gerade fasstiert und uns das alles anzuscheiden. Das funktioniert über den Hieb. Da können wir dann schauen, welche Strukturen von Windows gerade angefordert werden und alle zählen werden. Hieb ist sehr interessant. Zum Beispiel wenn wir die Mauser umbewegen, gibt es eine ganze Menge von Sachen, die gerade passieren. Wenn wir uns jetzt genauer für diese Strukturen interessieren, können wir auch das machen. Zum Beispiel, wenn wir wissen wollen, welche Dateien von Windows zugegriffen werden, können wir zum Beispiel schauen, welche Objekte im Speichel belegt werden. Das ist zum Beispiel die ganzen Dateien, die Windows im Hintergrund darauf zugreift. Das macht gar nix. Das passiert alles automatisch und es läuft immer noch weiter. Also wenn ihr ein Betriebssystem debacken wollt, ist das wirklich cool. Und ihr seht, das ist genau das, was jetzt im Moment passiert. Ich erzeug mal ein Dokument auf den Desktop und ihr seht, immer noch eine Menge los und ich habe nur eine einzige Datei eigentlich angelegt. Und ich müsste jetzt natürlich das ganze Protokoll erst mal durchschauen, ob überhaupt einmal die Datei vorkommt, die ich gerade angelegt habe und da war sie kurz gewesen. Ich habe es gar nicht mal wahrgenommen. Wir benutzen bei Xen zum Beispiel 4 verschiedene Typen von A.I.T.S. Wir können uns mal jetzt mal um Intel das reicht schon mal. Zum Beispiel 3 Kontrollregister, die vom Betriebssystem verwendet werden. Das CR3 beinhaltet die Page Table, die Ausführungsprozesse und verschiedene Optionen und das ist natürlich großartig. Das zweite, sind die Debugging Breakpoints, die wir verwenden können. Wenn wir mit so einer Sprühinstruktion Debugge verwenden, können wir hier auf den Hacks Hoppoint uns anschauen und wir können auf weitere Breakpoints setzen, sodass wir auch mitbekommen, wenn im Hypervisor etwas geschieht. Der andere Ereignis, die wir haben, sind die Excel Page Tables, die wir verwenden können. Viele weitere Page Tables, die dafür zuständig sind für das Mapping zwischen der Wettbewerbmaschine und heimerweise. Früher wurde das mit Shadow Page Table gewohnt. Das wurde alles von der Radwerk gemanagt und das Schöne ist, dass wir in den Extended Page Tables weitere Informationen setzen können und so können wir verschiedene Zugriffen natürlich mitverfolgen, wenn wir irgendwas zum Sprachen rausholen. Das zweite, sind die Monitor Trapping, die wir single-stepping und das können wir bei Intel Prozessoren machen und hier können wir wirklich in der einzelnen Ausführung ausführen. Es gibt auch noch eine ganze Menge andere Features, die bei Intel verwenden könnten, aber das sind zumindest die, die von Xen korrekt implementiert werden und das sind natürlich die coolen. Die ZAN API ist natürlich nicht besonders schön, es ist schwierig auszuführen, wie die Dinge zusammenarbeiten, aber zum Glück müssen wir das auch nicht machen. LibVMI ist ein Hypervisor Bibliothek, die den Hypervisor um ein ganzes Stück arbeitet. Das ist letztendlich eine Erweiterung für Xen, KVM und weitere Speicherabbilder. Ich habe auch vor kurzem Arm-Support hinzugeführt 32 und 44. Aber im Moment ist es erst von Windows und Linux. Es gibt ein Python-Deface, die können die Co-Eimer schreiben, dann den Hypervisor austauschen und Draupen aus. Also nichts mehr um irgendwas zu kümmern, denn wir schreiben die Co-Eimer und dann ist er fertig zu verwenden. Wir können in der Speicher schreiben und draus lesen. Es ist ein Drapper um Xen herum und es ist natürlich noch ein paar Details. Wir können es dadurch mit jedem Projekt verwenden, das wir implementieren möchten. Noch ein paar Details, wie genau das Tracing stattfindet. Wir haben zwar einen Breakpoint 0xCC eingefügt in den Code, das uns interessiert. Dass jetzt ausgeführt wird, müssen wir natürlich schauen, dass es fertig ist. Wenn die Originaladresse vom Stack holen und die Adresse getroffen wird, können wir in den Speicherbereich uns extrahieren. Es gibt natürlich eine Menge gefahren, die wir dabei beachten müssen. Zum Beispiel, während der Code ausgeführt wird, kann man wieder von anderen Teilen darauf zugegriffen werden auf den Speicher oder es gibt Prozesse, die wir beachten. Aber im Aufblick ist es eine Spicheradresse. Wir müssen also diese Speicherbereich immer selber überwachen. Zum Beispiel, wenn er ausgenullt wird und dann in Daten geführt wird, bis die Daten dort sind, die uns adressieren. Zum Beispiel der Zugriffsart auf eine Datei. Wir können also beobachten, dass es auf die gesamte Speicherseite, die wir anschauen, und wir müssen also weitere logische Schritte anwenden. Aber es ist zumindest ganz schön und ja, schön. Was toll ist, über Heaptracing ist, dass man sozusagen ein Kernel-Rocket-Mechanismatik treu ist. Das ist die Idee, dass man die Integrität von Kernel-Datenschrukturen brechen kann für Repräsentationen von Zustand. Man hat jetzt zum Beispiel ein Prozess in der Mitte, der nicht gefunden werden will vom Task Manager oder vom Benutzer. Der kann jetzt zum Beispiel anhoben von der Prozessliste und von den alle laufenden Prozesse enthält. Man sieht, dass man genau wie jede Struktur Allozi ist. Das heißt, damit umgeht man das Problem und das wird in die Daten vertauern. Man kann natürlich auch die Struktur, die ich auf der Adresse aliziere, aber die schaut nicht und dann kann ich natürlich auch sehen, wenn irgendwas manipuliert wurde. Schauen wir das mal an. Wir haben hier natürlich auch wieder alle Prozesse, die gerade laufen. Ich habe den Output ein bisschen vermindert, damit man überhaupt sehen kann, was hier los ist. Was ich euch hier zeigen will, ist, dass man wirklich jedes Ereignis fangen kann. Ich will jetzt hier fangen, dass ich meine Datei lösche und das Problem ist, dass das Filet von dem Speicher verschwunden ist, bevor es überhaupt von dem Riefesystem gelöscht würde und jetzt habe ich das natürlich hier gefunden. Ich war jetzt hier fähig, obwohl wir das die Datei gelöscht haben, das zu finden, weil Windows löscht das nicht wirklich. Und für wenn wir zum Beispiel etwas auf die Platte schreiben und eine Datei speichern, dann kommt sie nicht direkt auf die Fist-Platte, sondern wird von Windows einen Ruffer geschrieben und irgendwann später erstmal auf die Platte geschrieben. Wenn ich sie also auf die Platte anschauen würde, dann würde ich die Datei noch nicht einmal lesen, denn sie ist immer noch im Speicher. Für Shotsoft wäre es das zum Beispiel der Fall, denn es gibt auch Dropper, die erstmal nur im Speicher sind und dann alles aufwandt. Um also die Löschvorgänge zu finden, müssen wir schauen, wann es zum Beispiel speichern und recyceln wird, dann sehen wir zum Beispiel, dass es ein paar Dateien gab und dann können wir dort genauer hinschauen und sehen, was für Seite ich würde von Speicher bereichen. Es gibt also nur ein sehr kurzes Zeitpunkt Fenster und das ist natürlich recht kritisch für Shotsoft-Analyse. Schauen wir uns noch eine Demo an. Demos sind lustig. Dieses Mal habe ich Windows 64-Bit Informationen darüber. Also 64-Bit Windows 7 und da sind all die Prozesse, die laufen und wie wir sehen können, da ist der Task Manager 2.3.6.4 und was ich euch jetzt zeigen werde in der Demo ist, dass man komplette Kontrolle über die virtuelle Maschinen bekommen kann, anstatt nur Informationen zu sehen und ich werde jetzt den Task Manager wirklich überfallen, um Informationen aus der Maschine zu machen. Das heißt, dass ich nicht third-party Software installieren musste, um komplette Kontrolle zu bekommen. Ich muss einfach den Prozess kontrollieren, der die virtuelle Maschine kann. Dann kann ich machen, was ich mache, was auch immer ich will. Ich habe komplette Kontrolle, oder? Jetzt sieht man, was die Privilegien des Systems wirklich heißen und jetzt kann ich zum Beispiel Command.exe ausführen und dann jeden Sieg zu sehen. Man sieht wirklich auch, welche Prozesse kreiert wurden in der virtuellen Maschine und man kann das jetzt alles zusammen pipen, wie man will. Dann hat es wirklich eine externe Shell für die virtuelle Maschine und ich kann jetzt zum Beispiel auch eine Webseite, die ich will, auf der virtuelle Maschine anzeigen lassen und die virtuelle Maschine macht das einfach. Das heißt, ich kann wirklich genau kontrollieren, was in der virtuellen Maschine losgeht. Also, wenn man jetzt etwas setzen will, dann ist das toll. Man kann oft über die Maschine Software starten und die wieder schließen und das ist toll. Die Demos, die ich euch gezeigt habe, sind Teil eines Schadsoftware-Analyser-Systems RAG5. Das ist natürlich kostenlos zu verwenden und alle diese Demos stehen natürlich jetzt für euch bereit und wir können dann eben spielen. Ich denke, dabei ist natürlich, dass für Moldware-Analyser nicht alles in der Vereinbarung ist. Wir haben natürlich in Gast noch gewisse Artifakte übrig, was die Analyse schwieriger macht, aber wir können die ganzen temporären Dateien extrahieren, verpasst werden. So, da haben wir unsere Fotos wieder. Ja. Was ich euch zeigen wollte, ist risch gebacken. Also, wie ich gesagt habe, alle die Features built into Xamber wirklich designed for debugging. Also, warum nicht ein oder andere favorite debugger verwenden, in dem Fall GDB? Ich hatte jetzt keine Chance, das genau zu testen, denn es wurde gerade erst verliest. Aber wir können damit unsere Betriebssysteme und es ist ganz praktisch. Wir können auch die Integration von Winddebugger hinzufügen. Scheinbar, mal die Isolation. Kurz ab. Wir haben also eine der Sicherheitsmaßnahmen aus der Werte Maschine weggeschoben. Was wir dadurch natürlich geschoben haben, ist das Ziel. Ausdrückung von Lücken ist natürlich schwieriger, denn wir haben die Isolation ein bisschen hyperweißer, aber wir laufen jetzt in einem privilegierteren Teil des Systems. Wenn man da jetzt ausbrechen kann, natürlich auch viel mehr erreichen. Zum Beispiel haben wir erst vor Kurzem Local Privilege Eskalation, und wenn das System keine Schwachstellen hat, warum wollen wir dann nicht den Sicherheitsdeck von den wirklichen Werte Maschine isolieren? Dann hat es erreicht durch seine Accent Security Modules. Damit können wir die Trusted Computing Base verwenden, die wir bei Xen haben. Wir haben den Sicherheitsdeck natürlich nicht in Dom 0 hinzugefügt, denn wir haben verschiedene Domänen, die wir schützen möchten. Das funktioniert in dem Rapper für den hyperweißer Erzeug und dann definiert, wie die Interaktion zu den Freien geschehen darf. Das ist ein kleines Software-Stück, welches von der NSA geliefert und maintained wird. Also ohne ihre Arbeit wäre es nicht wirklich, das zu machen. Das ist letztendlich ein Rapper, um verschiedene Hypercalls und Flash ist die Engine, die die ganzen Policies definiert. Und es ist relativ ähnlich zu SC Linux. Zum Beispiel haben wir audit to allow, checkpollicy und so weiter. Das ist bei default zwar die App, aber es ist eigentlich nur richtig benutzbar von Xen 4.3 und ab Linux 3.8. Also in der frühe Redaktion des Systems angeschaut haben, haben wir rausgefunden, dass Körner zuerst selber noch im VR-Test ausführt, um zu sehen, ob es Dom0 ist und in dem Fall wurden die Hypercalls dann verweigert, um die Sicherheit zu gereist. Wenn wir aber definieren können, was erlaubt das oder nicht, dann muss es nicht der Körner machen. Wenn wir zum Beispiel die Rechte haben, Körnermodule einzuschieben, wenn wir da die Sicherheitsprüfung haben, ist das wirklich eine große Verbesserung und das so. Mit diesen Tools können wir aber auch Cloud Security nachdenken. Sie haben jetzt ein Mechanismus, um verschiedene Security Policy für verschiedene Benutzer zu haben in der Cloud. Okay, jetzt fangen wir an mit überwachen, bevor die Virtual Machine überhaupt Verbindung hat zu irgendwelchen Nutzen. Ich gehe das jetzt wirklich sicher erst mal. Und jetzt überwachen wir das alles. Und jetzt können wir wirklich sehen, ob irgendwelche kritische Datenstrukturen verändert werden, irgendwelche Inline-Hooks, die geändert werden. Und das heißt, wir können in Daten jetzt wirklich Daten vertrauen, die wirklich wichtig sind dafür, dass das System überhaupt weiterläuft. Denn wenn Schadsoftware die verändern würde, dann würde es einfach alles crashen. Aber wir sind zurück. Was für Daten können wir jetzt wirklich in dem System vertrauen? Zum Beispiel dieses Dings, was ich vorhin gesteigt habe, mit dem EBT werden wir jetzt hören. Es gibt auch Randfälle wie zum Beispiel Read, Modify, Write Instructions, die zum Beispiel dann für parallelisierende Mutex-Systems benutzt werden. Weil während es wirklich implementationsfilzifisches ist, lesen, dass Folgen 1045 gepatched werden, was nächstes Monat erscheint. Wir haben ein Paper geschrieben, welches all diese Sachen sammelt. Eine größere Begrenzung ist das Transaction Logo-Seit-Buffer betrachtet. Das gibt es seit 2008. Das ist letztendlich nicht die Frage, wie die ganzen Pages gemäht werden. Wenn wir nun ein geteckten tlb haben, dann sind die Pages nicht unbedingt diejenigen, die auch vom Betrübssystem verwendet werden. Wir müssen also schauen und emulieren, was das Gasbetriebssystem machen würde. Wenn wir ein geteckten tlb haben, bis ein Transients, dann sind das im Endeffekt assistente Einträge in der Tabelle. Wenn wir dann die Pages mapen, haben wir im Endeffekt keine Ahnung, was das Betriebssystem machen würde. Wenn wir dann sehen wollen, was eigentlich gerade läuft an Code, wissen wir nicht genau, was passiert und die Maschine führt vielleicht was ganz anderes aus. Es sind also davon ab, welchen Hyperweise und welches Gasbetriebssystem wir haben. Also, werden wir zum Beispiel Angriffe auf diese Einträge haben, dann ist zum Beispiel Windows relativ widersprachfähig, weil Windows diese Einträge regelmäßig flasht. Wenn wir aber andere Pagesysteme laufen haben, naja, das ist dann ein anderes Thema. Wenn wir über Cloud Security mal kurz nachdenken, dann eigentlich gibt es keinen Grund, alles nach aus in die Cloud zu schieben. Denn sicher mit Cloud Sicherheit möchten wir natürlich auch die VM am Laufe halten. Vielleicht würde es erreichen um die Sicherheit im Agenten zu haben, um sie vom Hyperweise bessere Visibilität in den System um bessere Performance und bessere Sichtbarkeit zu haben und in Gäste und Agenten interessiert dieses Problem. In den kommenden Intel CPUs gibt es die Virtualization Extensions, wo wir auch Traps im Gas setzen können. Ohne geht es mal nach auch zum Hyperweise zu schminken. So sehen wir dann, was die Code im System läuft und wir können kontrollieren, was das System macht. Also wir können nicht nur die Code, sondern auch die Daten kontrollieren. Eine andere Ansatz wäre zum Beispiel die Größe der Gasbetriebsysteme zu reduzieren. Zum Beispiel braucht man nicht immer einen kompletten Lidungsdeck. Es gibt zum Beispiel ein paar Arbeiten, die sehr richtig gehen, zum Beispiel Mirage OS oder LDSG, Rump Kernes und das Virtual Machine zu ein Prozess, und dann als Scheduler benutzt wird. Das ist ein bisschen ironisch, denn eigentlich sind sie ja, als sie eigentlich als Virtual Machine bezeichnet werden und irgendwie drehen wir uns dann ein bisschen im Kreis. Wir können natürlich auf dem Kern Gasbetriebsysteme absichern, zum Beispiel die Sachen, was zu verweigern ist. Dann muss man alle Dinge aufzählen, die viel schlafen können. Also ist ein besseres Ansatz ein weitest Ansatz. Wenn wir also die Sicherheit des Systemes gewährleisten wollen, müssen wir schauen, was da kann das System in den System ist und wir von Schadsoftware verändert werden kann oder nicht. Wir favorisieren also ein weitest Ansatz, damit können wir freigegebene Änderungen am System bzw. Kördel ausführen lassen. Dafür müssen wir natürlich aufzählen, welche Änderungen am System wir zulassen wollen. Das ist bei Linux ein recht einfaches Sache. Wir können den Code überprüfen, können den haschen und wenn die Hashes passen, dann ist der Kördel auch sicher. Linux macht aber auch Run Time Patching und damit haben wir Performance Optimierungen und wenn wir ein Linux Kernel aufhören müssen, müssen wir also unterscheiden zwischen den Änderungen am System. Wir sind bei Linux Kernel eine Sache, die easy Low Time Patching bewirkt. Zum Beispiel gibt es das Low Time Patching, Alternative Instructions, die architekturisch sind. Das ist natürlich von der Architektur abhängig. Es sinkt von Hyperweißer Art vom Betriebssystem und je nachdem wie der Hyperweißer gepatched ist, können manche Funktionen entweder auf die ein oder andere Weise implementieren. Run Time Patching können wir zum Beispiel machen, indem wir den Kernel auf einer Sicherung Gebung ausführen lassen, indem wir Hashes benutzen, aber da haben wir keine Probleme mehr. Wir haben aber auf Run Time Patching, welches vom Kernel ausgeführt wird, zum Beispiel bei Hodgeplug gereden. Wir wollen euch zwei Beispiele zeigen, wie das bei aktuellen Linux Kernels stattfindet, zum Beispiel SMP-Locks. Es ist eine Methode davon, wenn man alles in Totalisierung auf einem Gerät hat, dann will man Skalierbarkeit haben, zum Beispiel die Anzahl der CPUs, die einem System zugeordnet werden, können sich während der Laufzeit ändern. Das ist natürlich ein Problem, wenn man ein Single Thread-Betriebssystem hat, und wenn wir da irgendwelche Locks haben, haben wir bei einer CPU kein Problem. Das ändert sich, wenn wir mehrere CPUs haben, wir machen dann atomische Befehle. Und Atomic Operations werden vom Linux Kernel aber nicht verwendet. Wenn nur eine weitere CPU dazu kommt, werden all diese Stellen im Code gepatched, auf die Verwendung von Atomischen oder Befehlen. Und dieser Mechanismus kann auch benutzt werden, um komplette Funktionen in den Linux Kernel zu ersetzen. Das wird momentan nicht so verwendet im Moment, aber der Mechanismus ist eigentlich vorhanden. Ein Beispiel dafür ist zum Beispiel der Mechanismus, der sich Jump Levels nennt, den gibt es aus Performance-Gruppen. Zum Beispiel haben wir die Prüven im Linux Kernel dann just checking constantly you know, is it an unlikely case is it now an unlikely case you just patched out the jump to a certain code, servits output. But once those functionalities are enabled, for example by a user or by any hardware mechanism oder whatever, the Linux Kernel just patches the jumps into a code to the function that should be executed. With that we have the additional problem that we don't have like two possibilities that the jump is there or the jump is not there but the location where the jump points to also has to point to a location which is consistent with the entire system frame. And here you have the perfect thing for something return you are in the program where you just need to have an arbitrary jump in the code. Das sind natürlich Mechanismen gegen die wir uns verteidigen müssen. Um das zu überprüfen, gibt es ein paar einsfache Ansätze zum Beispiel die Kernel einfach zu spannen. Wir verweigern alle Änderungen am Kernel zur Laufzeit. Damit aktivieren wir aber auf alle Bedingungen. Auf der anderen Seite können wir natürlich auch sagen der größte Teil des Codes ist statisch, aber Teil davon kann sich ändern. Da natürlich eine Liste führen alle Orte die sich ändern könnte und das ist eine relativ große Anzahl und so müssten wir eine relativ große Liste pflegen. Auch der Linux Kernel gibt ein Problem, da manche Code-Seiten sowohl Code als auch Daten auf der gleichen Speicher-Seite existieren. Es werden letztendlich 2 Megabyte Pages verwendet, aber auf der letzten Page gibt es immer noch ein bisschen freien Speicher, der entweder nur verschwendet wird oder der Linux Kernel benutzt diesen Platz um ihnen Anwendungen zu zuweisen bei diesen Speicherabfahrten. Daher haben wir das Problem dass wir nicht genau wissen ob das jetzt Code ist oder da auch das ist also ein Problem für Caching. Das ist also ein Problem für die Kernel Caching. Hab ich jetzt BMI verwendet dann können wir Paching-Mechanismen ableiten was gibt es für Paching-Methoden und Bezüge-Systemen welche Offsets mit Programm-Codes welche Werte können gepatched werden und unter welchen Umständen geschieht das. Diese Paching-Mechanismen können mit mir natürlich aufspüren und versuchen zu verstehen was da passiert und das muss natürlich Konsistenz sein mit dem Systemzustand. Gerade wird auch ein anderes Problem erledigt, denn Code-Paching ist natürlich keine atomische Operation das kann natürlich nicht auf einen Schlag geschehen also haben wir immer zwischen zwei guten Zuständen einen schlechten Zustand und das ist natürlich immer schlecht zu einem Zwischenzustand zu haben. Wir brauchen also ein System welches auch diese Zwischenzustände kennt und damit umgehen kann. Wir wollen also die Schreibereignisse zum Kernel-Code abfangen und so kann da geprüft werden ob diese Änderung schädlich ist oder nicht und so können wir den laufenden Linus-Körnel die Integrität gewährleistet. Jetzt ging es größtendals um die Integrität des Codes und wir wollen es nochmal kurz zusammenfassen. Im Ergebnis können wir sagen Wirtel-Machine-Introspection unterstützt eine große Bandbreite von Anwendungen. Wir haben zum Beispiel Isolation Interpretation und Interposition Es hängt natürlich davon ab welches dieser drei Features wir am meisten haben möchten. Also reine Wirtel-Machine-Introspection ist nicht für all diese Fälle erforderlich. Wir müssen also schauen ob wir einen Agenten in der Gasfeuerung haben wollen oder ob wir sie lieber sicher haben wollen oder ob wir andere Mechanismen haben wollen. Also können wir abwägen zwischen Performance und Sicherheit. Ich habe bereits gesagt der Hardware-Support ist natürlich im Moment immer das Entwickelseh-Momente über weiter. Die Tools, die wir euch heute gezeigt haben sind Open Source Ihr könnt die Webseiten aufrufen LibVimee LibVimee on Freenode LibVimee on Freenode oder unsere Twitter-Erkan-Counts und ich möchte auch Dankeschön sagen an all die Personen die auf dieser Folie sind und ich dir das natürlich nicht möglich gewesen wäre. Und unseren Vortrag damit abschließen und wir warten auf eure Fragen. Wenn ihr Fragen habt, bitte an die Mikrofon und wenn ihr unbedingt rausgehen müsst, macht es bitte leise. Und geht bitte nicht vor der Kamera her. Es wird aufgenommen, also wenn ihr vor der Kamera hergeht, dann kommt der Kopf runter. Ich habe eine Frage über das Runtime-Packet-Patching Funktion-Patcher mit S-Trace und mit dem Exekörner-Patcher. Mit dem FSV-Feature funktioniert's Funktion-Trace und mit der Funktion-Replacement funktioniert's momentan nicht so sehr. Diese Tools sind auch Open Source, der letzte Teil wird noch veröffentlicht, aber es geht bald. Nr. 3 Nr. 4 Eine Frage wie ihr habt dieses Werkzeug gezeigt zum Tracing, also zum Verfolgen der Speicherzustände. Ihr habt erwähnt dass es nur unterstützt ist und auf der X86 Architektur das Pläne ist auf Arm zu unterstützen. Ja, da arbeite ich momentan ich will es von Version 4.5 verbinden, aber das Release-Render hat sich schon zu früh geschlossen. Ja, genau, denn es gibt diese 8-Core-Arm-Plattform und da wäre es toll, wenn man das hätte. Also, nächste Chip, kann ich es erwarten, dass es es gibt? Ja. Wunderbar. Frage vom Internet? Ja, es gibt eine Frage von IRC. Was war der einfachste Weg zum Hypervisor zu installieren und was sind die Requirements für Embedded Systems die Hardware-Requirements? Ich habe ein paar Sachen vom Quaker-Zelber kompelliert, aber vielleicht kann man es auch fertig beziehen. KVM ist natürlich im Kernel integriert. Das wäre natürlich eine Methode, wenn es die Hardware unterstützt. Und das andere hat auch ein bisschen Support. Mikrofon Nummer 4, bitte. Was ist die wirkliche Zweck dieser Werkzeuge? Es ist natürlich toll, wenn man ein System in einem isolierten Umgebung analysieren kann was schiefgegangen ist, was überfallen wurde von hardware, aber auf einem richtigen Live-System was mit Live-Packaging kann man halt keinen Fingerabdruck machen für Sicherheit und man kann es dann einfach nicht machen, denn man ist schon gefangen bevor man überhaupt irgendwas anfangen kann. Das ist dann, wo der Weitlist ansatz ins Spiel kommt wo wir nur die guten Sachen die im System geschehen sollen erlauben und als andere können wir als schädlich fliegen. Man muss aber die Weitlist updaten bevor man alles anabtätet. Ja, wenn man einen sehr aktuellen Kernel ausrollt, dann muss man das so machen. Was ist wenn jetzt Update Tag kommt und man bekommt dann einfach ein Keycraft-Kernel mit etwas bestimmtes Fix Das heißt, es könnte vielleicht geschnattert sein für dich, weil man nicht geschnattert sein für dich, sondern vielleicht ein ganz anderes Security-Problem hat und wenn der Host-Provider oder der Cloud-Provider noch gar nichts über diesen Zero-Day angefallen ist und das noch nicht fixen kann. Ja, aber das sind Generalisting für den Kernel-Integritäts-Teil und das ist sehr, sehr kernelspezifisch. Du musst genau wissen, welcher Kernel auf dem System läuft und du musst genau die Binaries haben und da musst du die ganze Information extrahieren über Bestätigung und Security. Also, wenn du als Cloud-Provider also, wenn du als Cloud-Provider also, wenn du als Cloud-Provider also, wenn du als Cloud-Provider also, wenn du als Cloud-Provider also, wenn du als Cloud-Provider das System machen, denn da wissen wir natürlich nicht, welche Patches und Systeme sind und wir wissen natürlich nicht, welche, wenn wir diese Patches anwenden, was läuft, sonst noch und wie können wir das mit dem System zusammenbringen, was sonst noch läuft. Ich bin mir jetzt nicht sicher, ob Cloud der richtige Begriff laut, den ich verwendet habe. Betrifft das nur das Betriebssystem oder den ganzen Sicherheitsdeck? Also das betrifft nicht nur die tatsächliche MOLV-Erkennung, wir müssen am Anfang ausgehen, dass das System sauber ist. Wenn wir dann mit dem System arbeiten, gibt es natürlich verschiedene Tools, die wir uns mit dem System anschauen können. Wenn das System irgendwelche komischen Sachen berichtet, dann müssen wir das natürlich genauer prüfen. Wir müssen natürlich immer mit der detailliertesten Methode an System herangehen. Das ist natürlich nicht mehr geeignet um alles an bösen Sachen im System zu vermeiden. Es geht aber in die richtige Gewichtung, es ist aber kein Tool, mit dem man alles bekommt. Das zweite was ich hatte ist, dass die erste Generation der CPUs, die man benutzt hat, die die VMs unterstützt haben, die hatten nichts, was war das? Die hatten eine Performance Unterstützung und die hatten das nicht und wenn man die hat, das ist nur 2 oder 5 % Performanceverbesserung und sollte man das immer aktivieren lassen. Ja, wir können dafür sorgen, dass die VM immer den Speicher flaschen. Wir haben natürlich eine beeinträchtigte Performance. Ja, irgendwie schon. Die Leistung ist also nicht irgendwie ein Argument dabei. Wenn man nur 2 % verliert, dann ist das egal. Es hängt davon ab, was für Smile-Einwendungen wir verwenden. Wir können natürlich nicht ganz schnellen Funktionen verwenden. Es hängt also davon ab, zum Beispiel, ob wir alles abfangen wollen, Traps setzen wollen oder nur auf Teile davon. Aber wir können es von außen schützen und bei Cloud anwenden ist das zum Beispiel der Weg, den man gehen sollte. Es ist die Frage, ob wir den Kerneldaten vertrauen können. Mikrofon Nummer 1 bitte. Bietet irgendeiner der großen Cloud Anbieter MOLLE Protection an? Nein, noch nicht, aber wir erwarten, dass das bald ist. Sie haben etwas erwähnt über Android. Wie weit sind wir da heute? Um Farmi-Wertum-Maschinen-Duspekt schon zu verwenden. Das Problem mit ARM ist, dass wir eine zweiteilige Paging haben. Wir wissen nicht, wie diese Mechanismus funktioniert. Das ist alles nur ein Teil. Es gibt verschiedene Arten von Traps. Wir müssen da also weitere Forschung durchführen. Zum Beispiel kann man Breakpoints abfangen. Das sind Dinge, die wir noch finden müssen. Aber es ist noch sehr früh in der Forschungsphase. Zum Beispiel Samsung ist sehr daran interessiert, sich so etwas anzuschauen. Wir möchten vielleicht ein paar Security-Sachen in Kürze verkaufen. Wird auf ARM volle Virtualisierung unterstützt? Ja, danke. Gibt es weitere Fragen? Ja, jetzt beenden wir den Vortrag. Auch wir sind am Ende. Vielen Dank, dass ihr uns zugehört habt. Wenn ihr Feedback oder Übersetzer habt, würden wir uns freuen.