 Wunderschönen guten Abend hier auf der Chaos-West-Bühne. Jetzt werden Jennifer und Christian, die beide irgendwie schon länger Cyber Security machen, über die einfache Erkennung von fortschrittlichen Rootkits reden und ich wünsche euch einen schönen Vortrag. Hi, danke, dass ihr alle hier seid. Vielen Dank auch nochmal an die Engel, die auch dieses Jahr den Kongress zum Leben erwecken. Vielen Dank auch für die Leute hinter der Kamera. Ja, wir sind heute hier, um euch ein bisschen was über die einfache Erkennung von fortschrittlichen Rootkits zu erzählen. Wir haben Schadsoftware aufgespürt, in dem wir einfach den Datenverkehr analysiert haben. Erstmal vielleicht ein bisschen was zu uns. Wer sind wir denn? Ich bin Jennifer, das ist Christian. Wir haben beruflich einiges gemeinsam. Wir haben als Netzwerkadministratoren gearbeitet, sind jetzt im IoT-Bereich in der Security angesiedelt und haben davor, als wir zu der Idee kamen, in der Informationssicherheit gearbeitet. Waren also daran interessiert, dass keine Daten abfließen. Daher kam es zu dieser Idee, die wir dann im Zuge meiner Masterarbeit weiterentwickelt haben und ausgefüllt haben. Wir haben in einem Hochsicherheitsbereich gearbeitet, also nicht im Knast, so wie es jetzt da aussieht, sondern in einer anderen Firma. Und da war halt das Wichtige, dass wir uns sicher sein können, dass keine Daten abfließen, weil das einen enormen Schaden verursacht hätte, auch geldmäßig. Und so sind wir zu der Idee gekommen. Also für Industrie Spürnage, das war eher so unser Augenmerk, eine spezielle Art von Hoodkits zu erkennen. Wir wollten nicht alles erkennen, dafür gibt es ja schon genug auf dem Markt für andere Malware und ein bisschen einfacheren Hoodkits. Wir wollten die Hardware dann speziellen Hoodkits entdecken, die nicht den Weg über das Betriebssystem gehen, sondern unterhalb des Betriebssystems sozusagen noch kommunizieren und die normalerweise nicht entdeckt werden. Der Vorteil war halt, dass wir uns nur auf diese Sache konzentrieren konnten, wo entgegen ja manch andere Lösungsansätze versuchen, mehrere Sachen zu greifen. Und deswegen konnten wir es hier sehr einfach umsetzen. Genau. Hier so ein bisschen, was euch jetzt den nächsten 40 Minuten erwarten wird. Auch ein bisschen eine kleine Zusammenfassung. Die Anforderung, die habe ich ja gerade schon erzählt oder erklärt, dass wir 100 Prozent erkennen wollten, was ja auch meistens nicht so leicht ist. Wir sind darauf gekommen, weil damals zu der Zeit, als die Idee entstanden ist, gab es schon die ersten Probleme beziehungsweise Lücken bei AMT von Intel. Das ist eine Software, wer es nicht kennt, womit man Remote sich auf PCs schalten kann und die warten kann, auf Tastatur und Monitor abgreifen kann. Und da wollten wir wissen, dass niemand uns Schaden zufügen kann mit dieser Sicherheitslücke bzw. ja, da ist ja gerade erst entstanden. Aber es war halt zu dem Zeitpunkt schon möglich, dass man mit einem USB-Stick, der präpariert ist, einfach an den PC gehen kann. Der musste nicht mal angeschaltet sein und dann schon die Lücke ausnutzen konnte und gewalt über den PC hatte bzw. Daten abfließen lassen konnte. Und so kamen wir auch zu der Idee, diese spezielle Art von Rootkits zu entdecken, nämlich die Hardware-Nahmen, die halt eben auch nicht über den TCP-IP-Stack das Betriebssystem kommunizieren, sondern halt an dem Betriebssystem vorbeigehen. Genau, was noch war, waren Firmware, die man manipulieren konnte oder Netzwerkkarten. Da haben wir ein bisschen eine Schwierigkeit, weil die ja nicht so viel Speicher haben, aber es war trotzdem möglich, mit einer manipulierten Netzwerkkarte schon auch, da es ja Hardware ist bzw. Firmware, Daten abfließen zu lassen. Die Herausforderung war die lückenlose Erkennung. Das haben wir immer. Es gibt nichts, was hundertprozentig sicher ist. Es sei denn, es ist offline und steht verschlossen im Schrank. Und dieser Datenabfluss ist prinzipiell schwer zu erkennen, weil Rootkits ja auch nicht so eine leichte Sache sind. Genau, was ich sagen wollte, wenn ihr uns später nochmal auf den Kongress sieht, könnt ihr uns auch gerne ansprechen. Falls ihr noch mal Fragen habt, könnt ihr die nachher ausstellen. Also hier bei diesem Vortrag gibt es keine dummen Fragen. Manche Sachen erklären wir vielleicht auch ein bisschen zu kompliziert, weil wir doch sehr technisch manchmal unterwegs sind. Genau, die Eigenschaften, die die Sache, die wir entwickelt haben, ausmachen sind, dass wir halt einen geringen Ressourcenverbrauch haben, weil wir die Datenpakete nicht direkt miteinander vergleichen, sondern Hash-Werte darüber bilden. Da gehe ich gleich später nochmal genauer drauf ein. Und die Hash-Snow vergleichen. Außerdem hinterlassen wir einen kleinen Footprint auf dem Klein-Mor. Und es gibt keine Redudanz zu schon vorhandenen Techniken, weil es das eigentlich so in dieser Art und Weise noch nicht gibt mit diesem einfachen Vergleich. Meistens wird KI, Machine Learning, solche Sachen benutzt, Signaturen werden verwendet und es wird auch gleich versucht, mehrere Sachen zu entdecken. Und meistens lernt der Algorithmus, das haben wir hier nicht. Wir gucken uns wirklich nur an, was gerade passiert und was rausgeht. Die Idee ist, deswegen ist sie nämlich so simpel, ein Soll ist vergleich der Datenströme. Und wir gucken uns dazu nur den erwarteten Datenverkehr im Betriebssystem an. Also wir setzen voraus, dass das Betriebssystem so kommuniziert und das nehmen wir als wahr an. Das ist das, was wir wollen. Und am Switch gehen wir eher mit einem Tap-Port, spiegeln das alles da nochmal und gucken, was vom Switch rausgeht ins Internet sozusagen und vergleichen diese beiden Datenpakete bzw. die Hash-Werte. Hier noch mal zum Anwendungsbereich. Wir wollten oder wir können mit dieser Art und Weise UEFI und oder BIOS Manipulationen entdecken, weil wir ja auch im Hardware-Bereich noch sind. Das BIOS wird ja bzw. lädt ja das Betriebssystem. Also kann das Betriebssystem ja Sachen, die dort passieren, noch nicht entdecken, genauso wie UEFI auch. Oder halt diese speziellen hardware-nahen Rootkits, die den TCP-IP-Stack nicht zur Kommunikation verwenden, den das Betriebssystem verwendet. Intel AMT hat ich gerade schon gesagt, da gab es ja immer mal wieder ein paar Problemchen. Oder halt manipulierte Hardware. Da können wir auch ja davon ausgehen, dass vielleicht irgendwann Interesse hat, schon etwas ein Gerät auszuliefern, wo ein Chip vielleicht manipuliert ist. Solche Sachen würden wir halt auch entdecken damit oder entdecken wir. Oder Firmware. Wichtig ist halt die 100-Prozent-Erkennung und das Kleingedruckte. Man sieht jetzt, wir entdecken die Sachen nur bei der Datenextraktion. Also wenn das Rootkit schläft, dann sehen wir nichts. Und genau, das ist halt auch ein bisschen das Besondere, aber das interessiert uns ja auch nicht. Also heutzutage ist es ja so, dass wir eher ein bisschen den Fokus auf Industrie-Spionage legen und da steckt ja eine Menge Geld hinter und eine Menge Zeit und da ist ja eher das Interesse, was auch was ein Rootkit ausmacht, sich einzuschleusen, ohne entdeckt zu bleiben, eine Weile lang eben keinen Tobabo anzurichten und dann teilweise auch nach Jahren des Schlafens mal ein paar Daten abfließen zu lassen, die der anderen Seite vielleicht Vorteile bringt. Und deswegen interessiert uns auch nur, wenn wirklich die Daten abfließen, weil dann wird es gefährlich, der Rest interessiert uns gar nicht. Hier haben wir mal schematisch so eine Darstellung von dem PC, da wir in dem Unternehmen, wo wir diese Idee entwickelt haben, nur Windows-Maschinen hatten, funktioniert im Moment nur für Windows, das ist aber auch denkbar für Linux, das ist kein Problem eigentlich. Wir haben hier UEFI oder das BIOS sozusagen zu Manipulationen und hier ist halt, sieht man ein bisschen an der Darstellung, dass alle Sachen auf den Speicher zugreifen können, entweder direkt oder durch Umwegung, deswegen ist es so gefährlich, weil dann direkt die Daten abfließen können oder auch Monitor-Tastature-Eingaben, solche Sachen können abfließen. Hier im Chapsets ist dann Intel AMT angesiedelt, kann auch über dem Prozessor auf den Speicher zugreifen. Wir haben der FI als Netzwerk-Triper sozusagen das Modem des Chipsats für die Netzwerk-Kommunikation, da würden wir zum Beispiel erwarten, dass man da irgendwelche Spionagechips platziert, weil ich soweit, ich weiß, die Kommunikation mit dem Chipsatz relativ offen gestaltet ist und auch der FI auf relativ viele Ressourcen im Computer zugreifen kann. Da gab es halt vor zwei Monaten ein relativ präsentes Beispiel, wo in China vermutet wurde, dass da solche Chips eben auf Mainboards gelötet wurden von einem großen Server-Mainboard-Hersteller. Das würden wir da mal vermuten. Nächste Werkratte, das war auch ein interessantes Thema, das ist schon relativ alt. Ich glaube 2010, fast schon, hatte eine Forschungsgruppe, die Firma einer Broadcom-Netzwerkrate sich mal vorgenommen und mal gezeigt, was man mit der Firma von der Netzwerkrate erst machen kann und da war es möglich, tatsächlich kompletten Zugriff auf den Hauptsprecher, auf alle Ressourcen des PCs zu erlangen, indem man eben entsprechende Funktionen in der Firma der Netzwerkrate platziert und dann kann man munter über PCI-Express, glaube ich, DMA und was alles an Technik zu Verfügung steht, den Hauptsprecher auslesen, natürlich auf, was sich Verschlüsselungsschlüssel zugreifen, Passwärter oder eben auf Nutzdaten und wahrscheinlich auch, wenn man das ordentlich implementiert, dann auf den Rate-Controller zugreifen und dort Daten extra hier. Und das ist tatsächlich was, was funktioniert hat, also nicht das mit dem Rate-Controller, aber ich glaube der Hauptsprecherzugriff, das hat funktioniert und ist natürlich dann auch ein valides Szenario, das wir dann betrachten mussten. Genau und hier nochmal das Rootkit, von dem ich die ganze Zeit schon erzählen, was auch den Titel hat. Wir haben es tatsächlich nicht mit einem richtigen Rootkit probiert, die Idee war da, ein eigenes zu schreiben oder sich eines zu besorgen, wie jetzt beispielsweise Blue Pill, falls es jemandem was sagt. Die Problematik war allerdings, dass wir nicht so viel Zeit hatten in der Maßarbeit, so viel zu machen und eine größere Problematik war, wenn man jetzt selber ein Rootkit geschrieben hätte, müsste es sehr gut geschrieben sein, damit wir eine Chance haben es zu entdecken. Also war nicht gegeben 100 Prozent damit herauszufinden, ob unsere Methode wirklich funktioniert in der Praxis und nicht nur in der Theorie. Deswegen haben wir uns Intel AMT genommen und mal geschaut, was da für einen Datenverkehr herrscht und ob wir den sehen und verwenden sozusagen diese Sachen als Sododym. Genau und hier dieser, der Unterschied ist halt, dass wir halt keinen Algorithmus haben, der noch lernen muss, sondern dass wir nur das angucken, was wir verwenden, also was rausgeht. Hier nochmal ein bisschen genauer die Funktionsweise. Wir haben ja gesagt einfache Erkennung, da sieht man, dass es auch eigentlich relativ einfach aussieht. Wir haben am Kleint das Betriebssystem, da schauen wir, also das Betriebssystem, da kann man ganz gut die Daten abgreifen, die das Betriebssystem raus sendet. Die greifen wir auch einmal ab, speichern die auf einem Monito-Server und das machen wir einfach, dass falls es später mal eine forensische Analyse geben soll, haben wir die Daten da und das kostet halt nicht so viel, allerdings hatte ich ja schon gesagt, dass wir ansonsten mit den Daten nichts machen, sondern eher ein Hash-Wert darüber bilden. Das ist auch sehr ressourcenschonend, weil wir halt also die Berechnung von so einem Hash-Wert, die geht relativ schnell, die kostet gar nicht viel und genau und halt das versenden sowieso nicht, weil das natürlich nicht das ganze Datenpaket ist, sondern nur so ein kleiner Wert. Und auf dem Server hatten wir dann eine Datenbank, wo die ganzen Hash-Werte von dem Betriebssystem, von dem also erwarteten Datenverkehr, wo wir gesagt haben, wir erwarten, dass dieser Datenverkehr der Richtige ist, der Äste, den wir haben wollen, haben wir da die Hash-Werte reingespeichert, dann haben wir am Switch ein Monitor-Port oder ein Tap-Port angelegt, der sozusagen alles, was über den Switch geht, spiegelt und haben dann dort auch Hash-Werte gebildet über die Datenpakete, die sind wiederum dann auch in den Monitor-Server eingelaufen und so konnten wir in der Datenbank einfach nur die Hash-Werte vergleichen, also eigentlich völlig simpel und haben dann gesehen, wenn Hash-Werte übrig geblieben sind. Wir haben natürlich hier ein bisschen mit Latents zu kämpfen, weil wir uns ja hin im Netzwerk befinden, das heißt, wenn die Pakete vom Betriebssystem da einlaufen auf dem Monitor-Server, dann werden die von dem Switch sozusagen ein bisschen länger brauchen und die werden dann nicht in der gleichen Reihenfolge unter Umständen ankommen, tun sie auch nicht immer. Deswegen haben wir immer Zeitfenster betrachtet, in der Zeit, wo die ankommen müssen, haben geguckt und die gleich, wenn sie gleich waren, haben wir die Hash-Werte rausgeschmissen in die Pakete und wenn sie nicht gleich waren, dann haben wir sie drin gelassen. Und dann wusste man relativ zeitnah, dass wir halt ein Problem haben. Da musste man halt schauen, wenn ich jetzt mehr Datenpakete vom Kleint habe, interessiert mich das eigentlich nicht, weil das geht ja nicht raus, das passiert auf einem Kleint, muss das noch alles sicher. Mich interessiert nur, wenn ich mehr Datenpakete am Switchport habe, also die raus ins Internet gehen, weil dann habe ich ja eine Datenextraktion und dann möchte ich das wissen. Die Methode, die wir da entwickelt haben, die war noch jetzt nicht so weit, dass sie jetzt irgendwie irgendwas gelöst hätte oder sonst was getan hätte, sondern sie gibt nur einen Alarm, da muss jemand kommen und gucken, ah, was ist da los, ein Paket schaut, wie schaut sich das Paket an und weiß dann halt Bescheid, was da gerade los ist. Genau, dann haben wir halt generell mal Wire Shark benutzt und überhaupt mal zu gucken, was kommt da so an und haben das mit AMT gemacht. Genau, also hier sieht man, deswegen jetzt zwei Screenshots aus dem Wire Shark, links haben wir den Datenverkehr, den wir am Switchport messen, der dort ankommt vom Kleint und rechts ist das, was über den Betriebssystem, über das hier, über den TCP-IP-Stack des Betriebssystems geflossen ist und wir haben es mal unten markiert, dass auf der linken Seite dann doch relativ viel mehr zu sehen ist, ich habe das ja mal größer gemacht und hier sieht man auch, das erste Paket ist noch identisch und dann sieht man links massiven Datenverkehr, der auf der rechten Seite im Kleint, im Betriebssystem nicht zu sehen ist. Im D-Fall ist es militches AMT-Datenverkehr, da haben wir das AMT gehackt und mal geguckt, was man damit machen kann und dann sieht man halt mit dieser Methode ganz einfach links mehr als rechts, das ist schlecht. Eine Sache noch, der Vorteil ist auch, wir haben viele ARP-Pakete, die sehen dann immer gleich aus, weil wenn wir Hash-Werte über Datenpakete bilden, dann bilden wir die über das ganze Paket und diesen Jahr sehen halt immer gleich aus, deswegen haben wir immer den gleichen Hash-Wert und das macht es auch nochmal ein bisschen schneller, weil wir natürlich dann wissen, wie die aussehen und die gleich wegschmeißen können. Hier mal mal visualisieren, wie das auf dem Server aussieht, das ist noch sehr hands-on, das kommt aus der Masterarbeit, ist noch eine ältere Version, aber das zeigt eigentlich sehr gut, okay man kann es nicht so genau erkennen, aber was wir gemacht haben, wir haben halt eine Datenbank, dort ist der Datenverkehr aufgelaufen vom Kleinen und vom Server, im oberen Bereich haben wir auf beiden Seiten die gleichen Hash-Werte, das ist soweit erwartete Datenverkehr. Was nicht erwartet ist, ist hier im unteren Bereich zu sehen, wenn einfach von dem Kleinen nichts kommt, dann haben wir hier die Hashes von den Paketen mal visualisiert, die unerwünscht sind und oben seht ihr vielleicht in der SQL-Abfrage Server mit RAW, das haben wir jetzt nicht dargestellt, aber da haben wir dann entsprechend den RAW-Datenverkehr, den wir dann analysieren können in der SQL-Datenbank und das ist das Schöne an der Lösung, die Pakete, wo oben links und rechts die gleichen Hashes sind, die werden dann einfach rausgeschmissen nach 100 Millisekunden glaube ich und alles was nur auf einer Seite vorhanden ist sozusagen, das können wir dann, haben wir dann sowieso in der Datenbank und können das schön analysieren. Ja, die Umsetzung erfolgte dann mit C-Sharp erst mal, warum, weil das ziemlich einfach war, das erstmal damit zu tun. Wir konnten einfach die Backen, wir konnten sehen, wie es funktioniert, was da passiert, weil theoretisch, wenn man sich die Sachen überlegt, sind hier mal ganz klar und praktisch gibt es dann so ein, zwei Probleme, mit dem man nicht gerechnet hat und es war uns halt wichtig, nicht ein fertiges Programm, sag ich jetzt mal zu erstellen innerhalb dieser Maßarbeit, sondern einfach ein POC da zu erstellen und sagen zu können, das funktioniert. Also die Theorie haben wir in die Praxis umgesetzt, damit wir danach halt noch daran arbeiten können. Und es hat funktioniert, wir hatten auch keine Blue Screens, was ich dann später ändern sollte. Genau, wir haben aber links ein paar Nachteile und zwar, die haben wir da schon festgestellt, wir haben ja da ein kleines Setup gehabt mit so zwei Clients, weil das ja für ein POC reicht, wir müssen da jetzt nicht 100 Clients an den Switch anschließen und da hat man schon gemerkt, wenn da ein paar Daten drübergingen, dass er irgendwann nicht mehr hinterher kam und dass wir dann Probleme hatten, dass wir Pakete verloren haben und damit klappt ja unsere 100% Erkennung nicht, weil die lebt ja davon, dass wir genau alle Pakete sehen, die kommuniziert werden. Und das war ein Nachteil, der uns dann wiederum zu einer anderen Idee geführt hat, auf die wir nachher gleich nochmal eingehen. Und diese Art war halt auch leicht zu erkennen, weil wir sind ja hier, befinden wir uns nicht auf der Hardware-Nahbene, die wir untersuchen mit dem C-Sharp, sondern wir befinden uns ja wieder auf der Software-Ebene und dadurch sind wir ja auch leicht angreifbar, wenn man mal verstanden hat, was wir tun. Und deswegen war die Idee auch ein bisschen tiefer zu gehen. Und wir hatten dann uns überlegt, dass es ziemlich gut wäre, ein Endes-Triper zu schreiben, da er halt ja auch noch unter dem Betriebssystem liegt und dadurch nicht so leicht angreifbar ist und vielleicht dazu noch ein paar Details dazu. Genau. Also ich würde mal kurz was über Endes erzählen. Das ist der Netzwerkstack von Windows. Und wie sieht der aus? Wir haben Betrittssysteme und Applikationen. Wenn die Daten verschicken wollen, dann verpacken die schön und geben das an Endes weiter, an den Endes-Protokoll-Triper, im meisten Falle TCP-IP. Also stark schematisiert. Bitte nicht zu wörtlich nehmen, aber so ungefähr funktioniert das. Und TCP-IP kümmert sich dann darum, dieses Paket an die Netzwerkarte weiter zu reichen, an den Netzwerkartentreiber, der dann den eigentlichen Paketversand vornimmt. Das kann man nutzen, indem man zwischen Protokoll und Netzwerkartentreiber den Filtertreiber setzt. Und Endes kümmert sich dann darum, dass tatsächlich alle Pakete, die man haben möchte, durch den Filtertreiber durchlaufen. Das ist schon mal sehr wichtig. Das ist eigentlich egal, was für ein Protokoll. Also man könnte das auch mit IPX machen oder was am Einfeld. TCP-IP v4, v6. Das sehen wir alles im Filtertreiber. Wir sehen auch alle Pakete. Das ist auch ganz wichtig. Also wir haben kein Packet-Loss, wie zum Beispiel wir haben Packet-Loss bei Win-Pick-App oder wir haben es auch mit Sharp-Pick-App gemacht. Das kommt, glaube ich, nachher auch noch. Also bei den klassischen, bei Weihau-Sharks zum Beispiel, wenn zu viele Datenpakete auflaufen und der Puffer voll ist, den Weihau-Shark nutzt, um die Pakete abzuarbeiten und zu visualisieren, dann werden diese Pakete fallen gelassen. Und das können wir uns natürlich mit dieser Lösung nicht erlauben. Wir brauchen die 100% Pakete, deswegen machen wir das mit dem Filtertreiber. Dann sehen wir alles. Wenn wir zu viel Daten bekommen, dann kümmert sich Endes darum, dass weniger Daten in den Treiberankommen, in dem den Betriebssystem signalisiert wird, bitte langsamer Daten schicken. Genau. Ein weiterer Vorteil im Filtertreiber ist, man kann einfach Pakete initiieren in den Datenstrom, man kann einfach Pakete bauen und die dann der Netzwerkarte präsentieren zum Verschicken, die kümmert sich dann darum. Das ist auch sehr, sehr nett und deswegen benötigen wir auch keine weitere Komponente dann auf dem Client, um nochmal so ein Paket versandt zu machen oder die Hashes, die wir generieren, zu versenden. Genau. Hier nochmal, wir haben es versucht zu visualisieren, dass, wie funktioniert es eben normalerweise, ohne Filtertreiber, schickt, nimmt der Endes Stack, das Paket entgegen, das geht über den TCP-IP-System, den Protokolltreiber direkt an den Netzwerkartentreiber und wird verschickt. Was wichtig ist noch für uns, wenn so ein Paket verschickt wurde, also wirklich verschickt wurde, dann signalisiert der Netzwerkartentreiber über einen separaten Mechanismus, also Asynchron, irgendwann dieses Paket habe ich verschickt. Dieser Paketversand ist nicht immer in der gleichen Reihenfolge, das hat Jennifer schon gesagt, sondern der Netzwerkartentreiber kann die Pakete umsortieren oder je nachdem, wenn auch mehrere Streams kommen von verschiedenen Prozessoren vielleicht oder was auch immer, dann gibt es da vielleicht Verschiebungen. Das heißt, die Bestätigung des Asynchrons wird wichtig. Wenn wir jetzt den Filtertreiber damit reinpacken, dann sieht das Ganze so aus. Endes bekommt mit, dass wir ein Filtertreiber haben und die Pakete gehen jetzt nicht vom TCP-IP an den Netzwerkartentreiber, sondern werden erstmal an den Filtertreiber übermittelt, zur weiteren Verarbeitung. Was tun wir damit? Die Funktion heißt Filter-Send Netbuffer-List, meistens. Dort bekommen wir Netbuffer über Mitte, das ist grob gesagt eine Datenstruktur, wo viele Datenpakete drin sind, die so eine Applikation verschicken möchte. Dort nehmen wir die einzelnen TCP-IP-Pakete raus und bilden darüber Hashes, die wir dann in den Datenstrom auch injizieren und an unseren Monitor servers schicken. Auf der anderen Seite, wenn die Pakete irgendwann mal verschickt wurden, gibt es eine andere Funktion, die dann vom sozusagen Netzwerkartentreiber angetriegt wird, das ist in unserem Fall Filter-Sendnetbuffer-List komplett. Dort stehen alle Pakete drin, die verschickt wurden. Da müssen wir dann nochmal ran und müssen die Pakete, die wir selber injiziert haben, aus dieser Liste extrahieren. Die dürfen wir leider nicht nach oben melden, sonst kriegen wir ein Bluescreen. Das haben wir, glaube ich, ausreichend häufig getestet. Bluescreen funktioniert auf jeden Fall sehr gut. Also ich kann mal zeigen, wie das so ein bisschen im Code aussieht. Das ist jetzt der hier. Das ist jetzt der Beispielcode von Microsoft für einen Filter-Dreiber. Deswegen ist der relativ umfangreich. In C ist der und dort gibt es mehrere Funktionen. Eine verpflichtende Funktion, die man umsetzen muss ist DriverEntry. Das ist die Funktion, die aufgerufen wird, wenn der Treiber sozusagen gestartet wird. Und dort kann man Funktionen definieren, die aufgerufen werden, wenn verschiedene Dinge eben in diesem Netzwerk-Stack passieren. In unserem Fall haben wir hier relativ viele Sachen drin. Wir brauchen nur zwei von diesen vielen Funktionen. Wir brauchen diese hier, die Filter sendet Bufferlist, wo wir unsere Hash generieren und eben die Komplietfunktionen, wo wir nochmal manipulieren, was wir nach oben durchreichen, wieder an den Protokoll-Dreiber, die CPIP, an welcher Pakete verschickt wurden. Wenn man diese Funktionen, die wir nicht brauchen, nicht implementiert, das ist auch ein Vorteil von dem Filter-Dreiber, dann werden die auch natürlich nicht angesprochen. Das heißt, der Endes-Dreiber guckt, ist die Funktion implementiert und wenn nicht, dann passiert hier kein Overhead, sondern das Paket wird gleich weiter an den Protokoll-Dreiber gereicht. Und in unserem Fall ist das von Vorteil, weil wir nur den ausgehenden Datenverkehr eigentlich analysieren und nicht den eingehenden Datenverkehr. Das ist jetzt, wie ein P-CAP im Moment zum Beispiel auch nicht möglich. Wenn ich das richtig weiß, zumindest zu der Zeit, konnte man nicht die Richtung definieren, welchen Datenverkehr man eigentlich haben will. Ich glaube, da ist vielleicht, hat sich das schon geändert, da waren glaube ich ein paar Leute dran, das umzusetzen. Und das macht dann halt auch eben wesentlich geringeren Ressourcenverbrauch. Weil wir gehen auch, also bei uns war das zumindest so jetzt in allen Bereichen, die wir uns angeguckt haben, bekommt man natürlich wesentlich mehr Daten, als man einem Kleinen verschickt und wir gucken uns nur wirklich die Daten an, die ausgehen. Ich kann nochmal eine Funktion zeigen, wie wir das umgesetzt haben. Das ist jetzt die Filter-Sendent-Buffalists, die wir hier verwenden. Also das sind die Microsoft- Funktionenamen, die haben wir jetzt einfach mal so gelassen, falls das mal irgendjemand nachbauen möchte, vielleicht. Da kommt das rein. Wir bekommen hier die Daten, die wir zu verschicken haben, übermittelt als variablen, sozusagen, und können dann über diese Punkte ja, können dann auf den Speicherbereich zugreifen und die Daten auslesen, die eigentlich verschickt werden sollen. Und dann ja durch dieses Konstrukt gehen, also wir bekommen eine Liste mit vier Netbuffern und in einem Netbuffer gibt es wieder MTLs, Memory Descriptor Lists, wo die eigentlich Daten drin stehen. Das heißt, wir müssen das ein bisschen verschachteln und dann bekommen wir aber hier in der Funktion alle Datenpakete und können dann darüber hier diese MT5-Hashes bilden. Was wir jetzt in der Version noch nicht sehen, ist, dass die auch verschickt werden, aber das haben wir später implementiert. Und jetzt nennen das, was dann am Schluss passiert, so als letzte Funktion ist, dass man das Originalpaket nochmal auf die Reise schickt, an die Netzwerke schickt. So sieht das im Kot aus. Im Vergleich zur anderen Lösung braucht der Algorithmus, weil es kein gibt, kein Training, um erstmal Schadsoftware zu erkennen, sondern entdeckt Datenabfluss gleich. Und wir erkennen 100 Prozent, haben wir gezeigt, das hat funktioniert, auch schon mit der anderen Lösung für kleine Kleintanzahl. Und wir haben dann halt auch die Datenpakete direkt da, um sie zu analysieren, falls es zu einer forensischen Analyse kommt. Und wir müssen halt nicht den ganzen Verkehr mitschneiden. Also die meisten Lösungen, die nehmen alle möglichen Daten auf, weil sie halt eben noch nicht verstehen, was sie sehen und was sie sehen müssen und was schlecht und was guter Verkehr ist. Und wir haben dann dadurch natürlich auch einen geringen Speicherbedarf, dadurch, dass wir mit diesen Hashes arbeiten und sie vergleichen. Aber halt normale Infektionen erkennen wir nicht. Irgendwelchen Fancy-Stuff erkennen wir auch nicht. Allerdings hat es auch den Vorteil, dass wir, also dadurch, dass wir nichts lernen müssen, erkennen wir halt auch neue Sachen, ganz einfach, weil uns ist ja eigentlich egal, wie die funktionieren. Das Wichtige ist bei dieser Lösung nur, dass sie halt eben nicht die Kommunikation übers Betriebssystem leiden, sondern schlauer sind und eben halt nicht den TCP-IP-Stack vom Betriebssystem verwenden, sondern einen eigenen aufmachen und darüber die Datenpakete abfließen. Und da ist uns auch egal, wie langsam das passiert, wie schnell das passiert, wie groß die sind, was in den Paketen drinsteht. Das ist uns alles egal. Wir sehen, da geht was raus, was das Betriebssystem nicht weiß. Nachteil ist allerdings, dass wir halt für diesen Monitor-Server, von dem ich vorhin erzählt habe, halt einen dicken Server brauchen, der eine Menge Power hat, weil wir da halt auch die Datenpakete zwischenspeichern, weil wenn wir davon ausgehen, dass wir auch ein paar Merklines haben, was ja meistens in den Unternehmen der Fall ist, leucht da ja dann doch ein bisschen mehr auf, auch mit den Hashes. Also da passiert ja doch eine Menge. Und da sollte der Server auch in der Lage sein, mit der Datenbank da die ganzen Vergleiche anstellen zu können. Und gegeben durch den Aufbau, dass wir halt ja eigentlich am Switch hängen, weil wir denen dazu hernehmen, die ganzen Ports, also der Tap-Port, da werden ja sozusagen alle Ports gespiegelt und beobachtet, beobachtbar gemacht. Und dadurch haben wir halt den Nachteil, dass wir jetzt beispielsweise Kleins, die im WLAN hängen, die da können wir nichts abfangen, da sehen wir nicht, was da passiert. Wir müssen halt alles über diesen Switch leiten. Und jetzt gerne Fragen. Danke. Wir haben eine ganze Menge Zeit für Fragen. Das reicht im Mikro. Funktioniert's? Ja. Habt ihr Probleme gesehen, dass der Switch zum Beispiel bei höhere Lastpakete gedroppt hat oder euer Monitor-Server und es dadurch so aussah, als ob ihr Pakete hättet, die da nicht hätten sein sollen? Und wie seid ihr damit umgegangen? Genau. Also wir haben das Problem mit Hardware erschlagen. Wir haben dann irgendwann Mellanox. Entschuldigung, darf ich das nicht sagen. Wir haben relativ schnelles Switch bekommen. Und wir haben vorhin auf dem Slide gehabt, also mit dem C-Sharpen, das mit 10 N-Bit. Die Switche, die wir dann hatten, waren 100 Gigabit Switche. Und die waren auch von der Performance ausreichend schnell, um alle Daten anzuliefern, damit da nichts auf dem Tap-Port, auf dem Monitor-Port verloren geht. Weil das passiert tatsächlich, wenn man nur einen Port überwacht, wenn man also nur einen Kleinen hat, dann geht eigentlich nichts verloren. Dann sieht man alles. Aber wenn man zwei oder drei Kleins hat und dann den Datenverkehr bündelt auf einem Tap-Port, dann kann es natürlich sein, wenn er zu klein dimensioniert ist, dass Pakete wegfliegen. Genau. Auf dem Monitor-Service oder auch einfach random, dass ein Paket... Wo andere Leute auch fragen? Das andere Mikro, bitte. Gibt es denn die Möglichkeit, den Buffer der Netzwerkkarte auszulesen und zu kontrollieren, ob da auch nur das drin steht, was man reingeschrieben hat? Dann könnte man das Ganze doch lokal machen, oder? Gute Frage, nächste Frage. Das hängt wahrscheinlich auch stark von der von der Netzwerkkarte ab. Vom Switch könnte ich jetzt mal behaupten, dass Pakete, die verarbeitet wurden, sofort aus dem Speicher entfernt werden. Oder in der Regel ja eigentlich, während die verarbeitet werden, sobald ein Bike gesendet wurde, ist das eigentlich nicht mehr interessant. Netzwerkkarten kann ich nicht genau sagen, aber das ist natürlich auch abhängig davon, was für ein Modell man hat. Also was für ein Hersteller und immer auch was für ein Modell. Und das haben wir ja, glaube ich, bei dieser Forschungsarbeit gesehen, die ich vorhin angesprochen habe von 2010 oder was mit dem Broadcom-Chip. Diese Firmware, die da geschrieben wurde, funktionierte nur in einem bestimmten, mit einem bestimmten Chipsatz, weil natürlich sonst andere Register, andere CPU-Drin und das ist schon sehr spezifisch. Genau, das ist auch die Spezialität, weil wir uns halt so hartwärner befinden, sind wir halt immer sehr speziell. Das weiß jeder, der sich damit so ein bisschen auseinandersetzt. Und deswegen war es auch eigentlich gerade so schwierig, diese Rootkits oder ist es so schwierig, diese Rootkits zu erkennen, weil sie sich halt so unterscheiden, weil die spezialisiert sind auf die Hardware und ja, das ist halt das Problem. Das ist recht in die Gruppe, bitte, wieder. Um nochmal bei den Netzwerkkarten quasi zu bleiben, stellt TCP offloading oder solche Netzwerk-Kartenfunktion ein Problem dar? Ja, da hat man nicht auffassgenau. Am Anfang haben wir schlicht vergessen, dass halt in der Checksam überall null drin steht und haben uns gewundert, warum das nicht funktioniert, weil im Ende Treiber sehen wir natürlich noch keine Checks, wenn die von der Netzwerkkarte gebildet werden. Zwar Möglichkeiten oder mehrere Möglichkeiten. Zum einen kann man das abschalten, das war die erste Lösung. Zum anderen können wir tatsächlich im Treiber auch Status-Meldungen verschicken und zwar Filter, oh Idee-Request sieht man es ja genau. Das ist die Funktion, mit der wir diese Funktionen in der Netzwerkkarte an- und ausstellen können. Das wäre die zweite Möglichkeit. Und die dritte Möglichkeit ist einfach entweder den HashServer im Treiber zu generieren. Wir haben uns aber dazu entschieden auf dem MonitorServer, wenn wir die Daten bekommen, bekommen wir das ganze Paket mit Checksam, die einfach auszunullen und bei der HashGenerierung im Client auch, egal ob da jetzt Checksum kommen oder nicht, die auch auszunullen. Das heißt, wir müssen uns ein bisschen mehr Arbeit machen. Das heißt, wir müssen schon gucken, was ist das für ein Paket? Das hatten wir am Anfang nicht. Da bekommen wir einfach nur einen Speicherblock, also zwei, drei Einträge in eine MDL und mussten das dann zusammensetzen und verstehen, was da passiert. Das ist bei TCP-IP nicht so komplex, muss man sagen. Da haben wir IP-Checksum und TCP-Checksum und das war es dann. Oder UDP vielleicht. Aber tatsächlich, das war ein Problem. Jetzt wieder die andere Seite. Hallo, könnte so ein RootKit im BIOS-UF auch selbst diese HashMessages injecten in den Datenstrom und dann vorgauen? Sehr schön, genau. Wir haben ja noch ein Slide. Danke schön für die Frage. Ja, das ist der mittlere Punkt. Natürlich gibt es sehr intelligente RootKits und bei RootKits haben wir die Problematik dann als Sicherheitsmenschen. Die haben quasi unlimitierte Ressourcen, weil die können halt beliebig groß sein, die kann man beliebig komplex machen. Das geht jetzt mit einer Netzwerkkarte, würde ich das ausschließen. Das heißt, nicht genügend Speicher um so was zu implementieren. Für MD15 braucht man wahrscheinlich so ungefähr anderthalb Kilobyte Assemblercode oder Maschinencode. Und wenn da kein Platz ist, dann kann man da keine Funktion simulieren. Das ist in dem RootKit anders und das war auch jetzt Teil oder ist jetzt auch der Entwicklung, die jetzt stattfindet, die super interessant ist. Wie können wir denn uns in einem untrusted Bereich, den wir nicht vertrauen, wie können wir da Vertrauen herstellen? Nur für uns, für unsere Funktionen. Und da haben wir uns einfach ein paar stumfe Sachen überlegt. Wir können zum Beispiel alle zwei Wochen mal den Treiber tauschen und dann nehmen wir nicht MD5 zum Herrsch generieren, sondern RC4. Wir benutzen übrigens MD5, das ist aber bei uns überhaupt gar kein Problem. MD5 ist ganz toll. Es macht keine langen Check-Summen und es ist ziemlich schnell. Die Problematik, dass das nicht sicher ist, haben wir ja nicht, weil wir um so eine Kollision zu berechnen, das dauert relativ lange. Und ich glaube, die Wahrscheinlichkeit, dass wir bei Datenpaketen bis 1500 Zeichen die Kollision bekommen, ist relativ gering. Deswegen ist für uns MD5 gut. Für alle anderen Anwendungs-Szenarien ist MD5 nicht gut. Das möchte ich noch mal ausdrücklich erwähnen. Genau und das ist schon was, worüber wir uns Gedanken gemacht haben. Wie können wir das eben dann verhindern? Und wenn wir jetzt zum Beispiel den Treiber einfach tauschen, also wir lassen nochmal eine Installationsroutine rennen und tauschen den Treiber aus und dann sieht die Funktionsböcke auch anders und wir gucken, dass die Abfolge der Pakete, der Funktion dann anders ist, dann nachher die hinten rauskommt. Wir bekommen ein anderes Produkt und wenn wir das installieren, dann würden wir jetzt im Moment noch davon ausgehen, dass das Rootkit keine Chance hat, sich darauf einzustellen und erst mal den Betrieb verhindern muss. Weil wenn es dann versucht, eine neue Funktion herunterzuladen, um auf diesen neue Treiber zu reagieren, dann sehen wir das ja schon. Das wäre jetzt was, was wir demnächst implementieren wollen. Und wenn wir schon da beim Ausblick sind, können wir auch noch sagen, dass wir mit den performanten Switchen, die wir da zur Verfügung hatten, das sind die Log Switche. Da kann man dann auch versuchen, die Hashes dann eben nicht in einem Server, Monitor Server zu generieren, sondern das können wir eigentlich im Switch machen, um hier die Slide zu vervollständigen. Recht, bitte. Vielleicht wegen dem lying Endpoint Problem. Ich glaube, das könnte ja prinzipiell nicht lösen, oder? Das meine, wenn ihr ein Rootkit darauf habt, wie wollt ihr sicherstellen, dass euer Kleint nicht lügt gegenüber eurem System? Genau, das ist genau die Frage, die wir haben und klar, das gibt keine sichere Lösung. Aber was wir bisher an Rootkits gesehen haben, ist, es gibt schon relativ komplexe Sachen. Ich glaube, Stücknetz war ziemlich komplex, was sowas angeht. Die waren wirklich dann auf dieses Szenario hingebaut, wo sie eingesetzt wurden, oder die Software. Und wenn man mit so was konfrontiert ist, ist es immer schwer, aber unsere Lösung war einfach zum Beispiel, dass eben dann die Funktionsweise des Programmes zu tauschen, und zwar in einer Form, die nicht vorhersehbar ist. Also, man kann einfach dann zwei Hessches bilden, dann machen wir erst mal MD5 und dann RC4 und zwei Monate später RC4 danach MD5, oder was auch einfach ein bisschen unvorhersehbar sein. Und da muss man halt die menschliche Komponente reinbringen, das kann man ein Maschinell nicht lösen, dieses Problem. Gut, und die letzte Frage, die ich sehe, da drüben, bitte. Habt ihr euch im Rahmen eurer Arbeit auch mit hardware security Elementen sozusagen auseinandergesetzt, seid ihr dem irgendwie begegnet? Ich hab das justisch nicht verstanden. Entschuldigung, seid ihr im Rahmen eurer Arbeit auch hardware security Elementen begegnet, die sozusagen schon in die CPU mit reinkommen, so was wie Intel, TXT zum Beispiel, was irgendwie in Form von einem hardware security Element, wie zum Beispiel einem TPM, Trusted Platform und Jule, ist das bei euch irgendwie ein Thema gewesen? Weil das soll ja genau dieses Problem lösen, dass man sozusagen ab dem Boot und sozusagen immer Hash-Werte bilden kann und den sogenannten PCR rein schreibt und dann sozusagen eine secure Bootchain aufbauen zu können. Ja, das Problem bei TPM ist, wenn ich das richtig weiß, dass TPM davon ausgeht, dass das BIOS und auch das Wavy BIOS vertrauenswürdig ist. Ja, das ist eine gute Frage. Da müsste ich jetzt vielleicht doch nochmal drüber nachdenken, aber können wir das Mikro nochmal haben? Dann sprechen wir aber später nochmal drüber. Ja, genau. Aber um deine Frage zu beantworten, nein, darüber haben wir uns noch nicht so wirklich viele Gedanken gemacht. Gut, ich sehe keine weiteren Fragen und das war es dann, vielen Dank für deinen Vortrag und falls ihr doch noch Fragen habt, dann könnt ihr sicherlich im Lauf des Amts noch auf die zukommen und vielen Dank. Dankeschön. Danke.