Lieber Zuschauer, dieser Untertitel wurde automatisch generiert von Trint und dementsprechend (sehr) fehlerhaft. Wenn du kannst, hilf uns bitte gute Untertitel zu erstellen: https://c3subtitles.de/talk/1169 Danke!
Wunderschönen guten Abend hier
auf der Caos Weltbühne,
jetzt werden Jennifer und
Christian, die beide
irgendwie schon länger Cybersecurity
machen, über die einfache
Erkennung von fortschrittlichen Hot Kids
reden und
ich wünsche euch einen schönen Vortrag.
Hi, danke, dass ihr alle hier seid.
Vielen Dank auch noch mal an die Engel,
die auch dieses Jahr den Kongress
zum Leben erwecken.
Vielen Dank auch für die Leute hinter der
Kamera.
Ähm ja, wir
sind heute hier, um euch ein bisschen was
über die einfache Anerkennung von
fortschrittlichen Hot Kids zu erzählen.
Wir wollen oder haben Schadsoftware
aufgespürt, indem wir einfach
den Datenverkehr analysiert haben.
Ist man vielleicht ein bisschen was zu
uns? Wer sind wir denn?
Ich bin Jennifer, das ist Christian.
Wir haben beruflich
einiges gemeinsam, haben als Netzwerk
Administratoren gearbeitet,
sind jetzt im IT-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 weiter entwickelt
haben und ausgefüllt haben.
Wir haben in einem Sicherheitsbereich
gearbeitet, also nicht im Knast, so
wie es jetzt 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 Geld
mäßig.
Und so sind wir zu der Idee gekommen.
Also für Industriespionage.
Das war eher so unser Augenmerk.
Ähm, eine also spezielle
Art von jetzt zu erkennen.
Wir wollten nicht alles erkennen, dafür
gibt es ja schon genug auf dem Markt für
andere Malware und
ein bisschen einfach einfacheren Budgets.
Ähm, wir wollten die Hardware an
speziellen Kits entdecken,
die nicht den Weg übers Betriebssystem
gehen, sondern unterhalb
des Betriebssystem sozusagen noch
kommunizieren und die normalerweise
nicht entdeckt werden. Der Vorteil war
halt, dass wir uns nur auf diese Sache
konzentrieren konnten,
wohingegen 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 soll ich jetzt die nächsten
40 Minuten erwarten?
Wird auch ein bisschen eine kleine
Zusammenfassung.
Ähm, die Anforderungen, die
habe ich ja gerade schon erzählt und
erklärt, dass wir 100 prozent erkennen
wollten, was ja auch meistens nicht so
leicht ist.
Ähm, wir sind darauf
gekommen, weil damals zu der Zeit als
Idee entstanden ist, gab es schon die
ersten Probleme bzw.
Lücken bei Intel von Intel.
Das ist eine Software,
die das nicht kennt, womit man remote
sich auf PCs schalten kann und
die warten kann, auf Tastatur und Monitor
abgreifen kann.
Und da haben wir natürlich irgendwie
wollten wir wissen, dass
niemand
uns Schaden zufügen kann mit dieser
Sicherheitslücke bzw.
da ist ja gerade erst entstanden.
Aber es war halt zu dem Zeitpunkt schon
möglich, dass man mit einem
USB Stick, der repariert ist, einfach
an den PC gehen kann.
Da musst du 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 Lucid Kits zu
entdecken, nämlich die Hardware
Narayen, die halt eben auch nicht über
den TCP IP Stick das Betriebssystem
kommunizieren, sondern an
dem Betriebssystem
vorbeigehen.
Genau was noch war, wann
Firmware, die man manipulieren konnte
oder Netzwerk hatten.
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 sehr
Hardware bzw.
Firma ähm 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.
Ähm und dieser Datenerfassung ist
prinzipiell schwer zu erkennen, weil
Blutkrebs ja auch nicht so eine leichte
Sache sind.
Aber genau was ich sagen wollte wenn
ja und wir uns später noch mal auf dem
Kongress sind, können wir uns auch gerne
ansprechen.
Falls Sie noch mal Fragen hat, könnte die
nachher ausstellen. Also hier bei diesem
Vortrag gibt es keine dummen Fragen.
Manche Sachen erklären mir vielleicht
auch ein bisschen zu kompliziert, weil
wir doch sehr technisch manchmal
unterwegs sind,
um genau die Eigenschaften,
die die Sache, die wir
entwickelt haben, ausmachen
sind das wir halten geringen
Ressourcenverbrauch haben,
weil wir die Datenpakete
nicht.
Direkt miteinander vergleichen, sondern
Messwerte darüber bilden ich später noch
mal genauer drauf ein
und die Hashes nur vergleichen.
Außerdem hinterlassen wir einen kleinen
Footprint auf dem kleinen Ohr
und es gibt keine Redundanz zu
schon vorhandenen Techniken, weil es
so in dieser Art und Weise noch nicht
gibt mit diesem einfachen Vergleich.
Meistens wird keine 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 nämlich so simpel
Ein Soll ist Vergleich der Datenströme
und wir gucken uns
dazu nur den erwarteten
Datenverkehr vom Betriebssystem an.
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 GbR mit einem Tappert,
spiegeln das alles dann noch mal und
gucken, was vom Switch rausgeht, ins
Internet sozusagen und vergleichen
diese diese beiden Datenpakete bzw.
die erschwerte.
Hier nochmal zum Anwendungsbereich.
Wir wollten oder wir können
mit dieser Art und Weise
UEFA und oder Beyers
Manipulation entdecken,
weil wir auch im Hardware Bereich noch
Sinn des BIOS wird.
Er bzw.
lädt ja das Betriebssystem, also kann das
Betriebssystem ja Sachen die dort
passieren noch nicht entdecken.
Genauso wie auch.
Oder dieser speziellen Hardware Animate
Kids, die den TCP
IP Stick nicht zur Kommunikation
verwenden, den das Betriebssystem
verwendet.
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
irgendwie ein Interesse hat, schon etwas
ein Gerät auszuliefern, wo ein Chip
vielleicht manipuliert ist.
Solche Sachen würden wir auch entdecken
damit oder Decken
oder Firma.
Wichtig ist halt die 100% Erkennung und
das Kleingedruckte.
Man sieht es jetzt.
Wir entdecken die Sachen nur bei der
Daten Extraktion.
Also wenn das Kind schläft, dann sehen
wir nix.
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 Industriespionage legen und
da steckt eine Menge Geld und auch eine
Menge Zeit. Und da ist ja eher das
Interesse, das auf was einem gut geht,
ausmacht, sich einzuschleusen,
unentdeckt zu bleiben, eine Weile lang
kein Tohuwabohu anzurichten
und dann teilweise
auch nach Jahren des Ladens 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 können, weil dann wird es
gefährlich, der Rest interessiert uns gar
nicht.
Hier haben wir mal schematisch so eine
Darstellung von einem PC.
Da wir in dem Unternehmen, über das diese
Idee entwickelt haben, nur Windows
Maschinen hatten, funktioniert im Moment
nur für Windows, ist aber auch denkbar
für Linux das kein Problem eigentlich.
Wir haben hier am
Ovi oder die oder
das BIOS sozusagen zur Manipulation.
Und hier ist halt sieht man ein bisschen
an der Darstellung, dass alle Sachen
auf den Speicher zugreifen können,
entweder direkt oder durch Umwege.
Und deswegen ist das so gefährlich, weil
dann direkt die Daten abfließen können
oder auch Monitor, Tastatur,
Eingaben. Solche Sachen können abfließen.
Hier im Chipsatz ist ein Shantanu
angesiedelt.
Man kann auch über den Prozessor auf
den Speicher zugreifen.
Der Fall als
der Treiber, sozusagen das
Modem der des Chip
Satzes für die Netzwerk Kommunikation.
Da würden wir zum Beispiel erwarten, dass
man da irgendwelche Spionage Chips
platziert, weil ich
soweit ich weiß, die Kommunikation mit
dem Chipsatz relativ offen gestaltet ist
und da auch der Fall auf relativ
viele Ressourcen im Computer zugreifen
kann.
Da gab es vor zwei Monaten
ein relativ interessantes
Beispiel, da 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.
Und.
Soweit
Netzwerkkarte, das war auch ein
interessantes Thema.
Das ist schon relativ alt.
Ich glaube 2010 fast schon
hatte eine Forschergruppe
der Firma eines Brand
einer Fortkommen erzeugt, hatte
sich mal vorgenommen und mal gezeigt,
was man mit der Firma von einer Kralle
machen kann.
Und da war es
möglich, tatsächlich kompletten
Zugriff auf den Hauptspeicher auf
alle Ressourcen des PCs zu erlangen,
indem man eben entsprechende Funktionen
in der Firma Netzwerkkarte platziert.
Und dann kann man munter über
das Thema und was alles
an Technik zur Verfügung steht,
den Hauptspeicher auslesen.
Natürlich auf was sie sich verschlüsselt.
Schlüssel zugreifen, Passwörter oder
eben auf Nutzdaten und wahrscheinlich
auch wenn man das ordentlich
implementiert, dann die
auf den Controller zugreifen und Daten
extrahieren.
Und das ist tatsächlich etwas, was
funktioniert hat. Also nichts mit dem
Ricco Tool, aber ich habe der
Hauptspeicher Zugriff. Das hat
funktioniert und ist dann natürlich ich
dann auch ein valide Szenario, das wir
dann betrachten mussten.
Und hier noch mal das Mitglied, von dem
ich die ganze Zeit schon erzählen muss,
auf den Titel hat.
Wir haben es tatsächlich
nicht mit einem richtigen Hut probiert.
Die Idee war da ein
Buch zu schreiben oder sich eins zu
besorgen, wie beispielsweise falls es
jemand was sagt.
Die Problematik war allerdings, dass wir
nicht so viel Zeit hatten, in der
Masterarbeit so viel zu machen und
eine größere Problematik war.
Wenn man jetzt selber ein Budget
geschrieben hätte, müsste es sehr gut
geschrieben sein, damit wir
eine Chance haben, es zu entdecken.
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 an der Hand
genommen und mal geschaut, was da
von Datenverkehr herrschen, ob wir denn
sehen und verwenden
sozusagen diese Sachen als Synonym.
Genau und hier dieser ähm.
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 noch mal ein bisschen genauer die
Funktionsweise.
Wir haben dann gesagt einfache Erkennung.
Da sieht man, dass es auf eigentlich
relativ einfach aussieht.
Wir haben am Client
das Betriebssystem, da schauen wir also
das Betriebssystem. Da kann man ganz gut
die Daten abgreifen, die das
Betriebssystem aussendet.
Die greifen da auf einmal ab und
speichern die auf einem Monitor Server.
Und das machen wir einfach, dass falls
es später mal eine forensische Analyse
geben soll, haben wir die Daten da
und es kostet halt nicht so viel.
Allerdings hatte ich ja schon gesagt,
dass wir ansonsten mit den Daten nichts
machen, sondern eher ein Beschwert
darüber bilden, dass es auch sehr
ressourcenschonend, weil wir halt.
Also die Berechnung von Messwerte geht
relativ schnell, die kostet gar nicht
viel.
Und genau
das versenden sowieso nicht, weil es
natürlich nicht das ganze Datenpakete
ist, sondern nur so ein kleiner Wert.
Und auf dem Server hatten wir dann eine
Datenbank, wo die ganzen
Messwerte von dem Betriebssystem, von
dem also erwarteten Datenverkehr, wo wir
gesagt haben, wir erwarten, dass dieser
Datenverkehr der Richtige ist, der Beste,
den wir haben wollen, haben
wir da rein gespeichert.
Dann haben wir einen
am Zug, einen Monitor oder ein Typekit
angelegt, der sozusagen alles, was
über den Switch geht, spiegelt.
Und haben dann dort auch
Messwerte gebildet über die Datenpakete.
Die sind wiederum dann auf einen
Monitor Server eingelaufen
und so konnten in der Datenbank einfach
nur die Hash Werte vergleichen.
Also eigentlich völlig simpel und
haben dann gesehen, wenn hier Werte übrig
geblieben sind. Wir haben natürlich hier
ein bisschen mit Latenz zu kämpfen, weil
wir uns in dem Netzwerk befinden.
Das heißt, wenn die Pakete vom
Betriebssystem Narayen laufen auf dem
Monitor Server, dann
werden die von dem Switch sozusagen
ein bisschen länger brauchen und sie
werden dann nicht in der gleichen Reihenfolge
unter Umständen ankommen.
Tun Sie auch nicht immer das.
Sie haben ja immer ein Zeitfenster
betrachtet in der Zeit, wo die ankommen
müssen, haben geguckt und sie gleich.
Wenn sie gleich war, haben wir die
Schwerte rausgeschmissen, die Pakete.
Und wenn sie nicht gleich war, 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
Client habe, interessiert mich
das eigentlich nicht, weil das geht da
nicht raus. Das passiert auf einen
Client, das ist noch alles sicher.
Mich interessiert nur, wenn ich mehr
Datenpakete am
Switch fort habe, also die raus
ins Internet gehen, weil dann habe ich ja
nur Daten Extraktion und dann möchte ich
das wissen.
Die Methode, die wir da entwickelt haben,
die war noch 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, was ist da los?
Ein Paket schaut wie, schaut sich
das Paket an und weiß dann halt Bescheid,
was da gerade los ist.
Und genau.
Dann haben wir halt generell mal
benutzt, um überhaupt mal zu gucken, was
kommt da so an und haben das mit Anti
gemacht.
Genau hier sieht man das sind jetzt zwei
Screenshots aus dem Beitrag Links
haben wir den Datenverkehr, der wir an
Switch Port messen, der dort
ankommt vom vom Client.
Und rechts ist das was über den
Betriebssystem, über das Ziel, über den
diese Friedenswerk, das Betriebssystem
geflossen ist.
Wir haben es mal unten markiert,
das auf der linken Seite dann doch
relativ viel mehr zu sehen ist.
Ich habe das ja immer 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 Client
Betriebssystem nicht zu sehen ist.
In dem Fall ist es es
ein Datenverkehr.
Da haben wir die 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 Wir haben
viele Pakete, die sehen dann
immer gleich aus, weil wenn der beschwert
über Datenpakete bilden, dann würden
wir die über das ganze Paket in diesem
Jahr sehen, immer gleich aus.
Das haben wir immer den gleichen Hash
wert und das macht es auch noch mal ein
bisschen schneller, weil wir natürlich
dann wissen, wie die aussehen und die
gleich wegschmeißen können auch.
Genau die aber mal visualisiert
wird, es auf dem Server aussieht, das ist
noch sehr.
Das kommt aus der Masterarbeit, ist noch
eine ältere Version, aber das zeigt
eigentlich sehr gut.
Okay, man kann es nicht so genau
erkennen, was wir
gemacht haben. Wir haben eine Datenbank,
dort ist der Datenverkehr aufgelaufen,
verkleidet und vom Server.
Im oberen Bereich haben wir auf beiden
Seiten die gleichen Werte.
Das ist soweit erwartete Datenverkehr.
Was nicht erwartet ist, ist ja im unteren
Bereich zu sehen.
Wenn auf Flipp von dem Client nichts
kommt, dann haben wir hier
die Hashes von den Paketen
mal visualisiert, die
unerwünscht sind.
Und oben seht ihr vielleicht immer in der
aktuellen Abfrage Server mit Roadies
dargestellt, aber wir haben dann
entsprechend den Datenverkehr,
den wir dann analysieren können, in
der SQL Datenbank.
Und das ist das Schöne an der Lösung.
Die Pakete
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.
Genau, ja.
Die Umsetzung erfolgte dann
mit C Sharp erst mal, warum?
Weil es ziemlich einfach war, das erste
Mal 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 wir
mal ganz klar.
Und praktisch gibt es dann so ein, zwei
Probleme, mit denen man nicht gerechnet
hat.
Und es war uns wichtig, nicht ein
fertiges Programm,
sage ich jetzt mal zu erstellen innerhalb
dieser Masterarbeit, sondern
einfach dazu erstellen
und sagen zu können das funktioniert.
Also die Theorie haben wir in die Praxis
umgesetzt, damit wir danach noch daran
arbeiten können.
Und es hat funktioniert.
Wir hatten auch keine Blueprint, was sich
dann später ändern sollte.
Ja, genau.
Wir haben aber längst ein paar Nachteile.
Und zwar haben wir da schon festgestellt,
wir haben ja ein kleines Setup gehabt mit
so zwei Claims, weil das ja
für einen PC reicht.
Wir müssen da jetzt nicht 100, sondern
sich anschließen.
Und da hat man schon gemerkt, wenn da ein
paar Daten drüber gingen, dass
er irgendwann nicht mehr hinterher kam
und dass wir dann ein Problem hatten,
dass wir Paket Pakete verloren haben.
Und damit klappt ja und 100 prozent
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
die diese Art war halt auch
leicht zu erkennen, weil wir sind ja hier
befinden wir uns nicht auf der Hardware
Narayen Ebene, die wir untersuchen
mit der, mit dem Sie Sharp, sondern wir
befinden uns ja wieder auf der Software
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, einen Treiber 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.
Also ich würde mal kurz
was über alles erzählen.
Das ist so ein Netzwerk
von Windows.
Und wie sieht der aus?
Wir haben Betriebssystem und
Applikationen.
Wenn die Daten verschicken wollen, dann
verpacken die sie schön und geben das
Allendes weiter.
Denn das Protokoll Treiber meistens
TCP IP also
stark thematisiert, bitte nicht
zu wörtlich nehmen, aber so ungefähr
funktioniert das.
Und TCP
kümmert sich dann darum, dieses Paket an
die Netzwerkkarte weiterzureichen, an ihr
Netzwerk Treiber, der dann den
eigentlichen Packet Versand vornimmt.
Das kann man
nutzen, indem man zwischen Protokoll
und Netzwerkkabel Treiber
den Filter Treiber setzt
haben und kümmert sich darum, dass
tatsächlich alle Pakete, die man haben
möchte, durch den Filter Treiber
durchlaufen. Das ist schon mal sehr
wichtig. Das ist eigentlich egal was für
ein Protokoll. Also man könnte das auch
mit IPs machen oder was einem einfällt.
Ähm TCP, IP, V4,
V6, das sehen wir alles
im Filter Treiber.
Ähm, wir sehen auch alle Pakete.
Das ist auch ganz wichtig.
Sie haben kein Paket los, wie zum
Beispiel wir haben Pakete bei
bei will Pick up oder es
mit Scharping hat gemacht.
Das kommt nachher auch noch.
Also bei den klassischen, bei Beiersdorf
zum Beispiel. Wenn zu viel Datenpakete
auflaufen und der Puffer voll ist,
dem Wahltag nutzt, um die
Pakete abzuarbeiten und zu visualisieren,
dann werden diese Pakete fallengelassen.
Und das können wir uns natürlich mit
dieser Lösung nicht erlauben.
Wir brauchen 100 prozent Pakete, deswegen
machen wir das mit einem Filter drüber.
Dann sehen wir alles.
Wenn wir zu viel Daten bekommen, dann
kümmert sich darum, dass weniger Daten
in dem Treiber ankommen,
in dem dem Betriebssystem signalisiert
wird Bitte langsamer Daten schicken.
Genau.
Ein weiterer Vorteil im Filter Treiber
ist Man kann einfach Pakete editieren in
den Datenstrom. Man kann einfach Pakete
bauen und die dann
der Netzwerkkarte präsentiert 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
noch mal so ein Paket versandt zu machen
oder die Hashes die wir generieren
zu zu versenden.
Genau dann hier noch
mal Wir haben versucht zu visualisieren,
das wie funktioniert
es eben normalerweise eben ohne
Grund und ohne
Filter Treiber
nimmt, Schicksal nimmt,
der steckt das Paket
entgegen.
Das geht über den TCP IP
in dem Protokoll
Treiber direkt an der Netzwerkkarte
Treiber und wird verschickt.
Was wichtig ist noch für uns.
Wenn so ein Paket verschickt wurde, also
wirklich verschickt wurde, dann
signalisiert der Netzwerkpartner Treiber
über einen separaten
Mechanismus. Also asynchron
waren. Ja, dieses Paket habe ich
verschickt.
Diese Pakete versandt ist nicht immer in
der gleichen Reihenfolge der aktuelle
Forscher gesagt, sondern das
Netzwerk hat bei Bekannten 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 Grundes
wird wichtig. Wenn wir jetzt den Filter
Treiber damit rein packen,
dann sieht das Ganze so aus.
Das bekommt mit, dass
wir mit Filter Treiber haben und die
Pakete gehen jetzt nicht von diese
initiale Netzwerkkarte Treiber, sondern
werden erst mal einen
Filter Treiber übermittelt zur weiteren
Verarbeitung.
Was tun wir damit?
Die Funktion heißt Filter sind einfache
Lists meistens
und dort
bekommen wir Buffer
übermittelt ist es grob gesagt in eine
Datenstruktur, wo viele
Datenpakete drin sind, die so eine
Applikation verschicken möchte.
Dort nehmen wir die einzelnen
Typekit Pakete raus
und bilden darüber Hashes,
die wir dann in den Datenstrom
auch injizieren und an unseren Monitor
Server schicken.
Auf der anderen Seite wird die Pakete
irgendwann mal verschickt wurden,
gibt es eine andere Funktion,
die dann vom sozusagen Netzwerk
Haupttreiber angetriggert wird.
Es ist reiner Zufall.
Filter sendet Bundesliste komplett.
Dort stehen alle Pakete drin, die
verschickt wurden. Dann müssen wir da
noch mal 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 losgeht.
Das haben wir glaube ich ausreichend
häufig getestet.
Lucent funktionieren auf jeden Fall sehr
gut. So ist.
Also ich kann dir mal zeigen, wie das so
ein bisschen im Code aussieht.
Ähm, das ist
jetzt der Herr.
Das ist jetzt der Code von Microsoft
für einen Filter Treiber.
Deswegen ist er relativ umfangreich.
Ähm
in C ist der und
dort gibt es mehrere Funktionen.
Eine verpflichtende Funktion,
die man umsetzen muss, ist Driver Entry.
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 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 seit der Wache ist, wo wir
unsere Haefs generieren und die die
komplett Funktion, wo wir noch mal
manipulieren, was wir nach oben
durchreichen, wieder den Protokoll
Treiber TCP, IP,
welche Pakete verschickt wurden, wenn
man diese Funktionen,
die wir nicht brauchen, nicht
implementiert. Das ist auch ein Vorteil
von dem Filter Treiber.
Dann werden die auch natürlich nicht
angesprochen und das heißt der Treiber
guckt, ist die Funktion implementiert und
wenn nicht, dann passiert hier kein
Overhead, sondern das Paket wird gleich
weiter an dem Protokoll Treiber gereicht.
Und in unserem Fall ist es von Vorteil,
weil wir nur den ausgehenden Datenverkehr
analysieren und nicht den eingehenden
Datenverkehr.
Das ist jetzt mit Pick-Up im
Moment zum Beispiel auch nicht möglich.
Wenn ich das richtig weiß, zumindest zu
der Zeit, konnte man nicht die, die
die Richtung definieren, welche
Datenverkehr man eigentlich haben will.
Ich glaube, da ist vielleicht hat sich
das schon geändert.
Da war, glaube ich, ein paar Leute daran,
das umzusetzen.
Und das macht dann halt auch einen
wesentlich geringeren
Ressourcenverbrauch, weil wir genau 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 eine kleine verschickt.
Und wir gucken uns nun wirklich die Daten
an, die ausgehen.
Ich kann noch mal eine Funktion zeigen,
wie wir das umgesetzt haben.
Das ist jetzt die Filter
sendet Verlusts, die wir hier verwenden.
Also das sind die, die Microsoft Funktion
nahmen. Die haben 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 Variable sozusagen
und können dann über das Bauteil,
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 vielen davon und
in einem Wellpappe gibt es wieder Apps
Memory des Kapitalismus, wo die
eigentlichen Daten drinstehen.
Das heißt, wir wissen das ein bisschen
verschachtelt und dann bekommt man aber
hier in der Funktion alle
Datenpakete und können dann darüber
hier diese fünf Hashes
bilden.
Was wir jetzt in der Version noch nicht
sehen ist, dass die auch verschickt
werden. Aber das haben wir dann später
implementiert und letzten Endes.
Was dann am Schluss passiert, so als
letzte Funktion ist, dass man das
Original Paket noch mal auf die Reise
schickt, da die Netzwerkkarte schickt.
Ja, so sieht das im Code aus.
Narayen Im Vergleich zu anderen Lösung
braucht der Algorithmus, weil es kein
gibt, kein Training, um erst mal
Schadsoftware zu erkennen,
sondern entdeckt Daten am Fluss
gleich.
Und wir erkennen 100 prozent haben wir
gezeigt. Das hat funktioniert.
Auch schon mit der anderen Lösung für
kleine kleine Anzahl.
Und wir haben dann
auch die Datenpakete direkt da, um sie zu
analysieren, falls es zu einer
forensischen Analyse kommt.
Und wir müssen nicht den ganzen Verkehr
mitschneiden. Die meisten Lösungen.
Die nehmen alle möglichen Daten auf, weil
sie 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 arbeiten und
sie vergleichen.
Aber halt normale Infektionen
erkennen wir nicht an irgendwelchen
Fernsehstars, erkennen wir auch nicht.
Allerdings hat es auch den Vorteil,
dass wir dadurch, dass wir nichts lernen
müssen, erkennen wir halt auf 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
leiten, sondern schlauer sind und
eben nicht in TCP IP 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 etwas raus, was das
Betriebssystem nicht weiß.
Ähm.
Nachteil ist allerdings, dass wir halt
für diesen Monitor Server, von dem ich
vorhin erzählt habe RAM halten,
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 mehr kleine haben, was ja
meistens in den Unternehmen der Fall ist.
Ähm läuft
er ja dann doch ein bisschen mehr auf,
auch mit den Hashes. Also da passiert ja
doch ne Menge.
Und da sollte der Server auch in der Lage
sein, mit der Datenbank da
die ganzen Vergleiche und Vergleiche
anstellen zu können und
gegeben durch den Aufbau, dass wir
ja eigentlich am Switching, weil wir
den dazu hernehmen.
Ähm, die ganzen Ports, also
der Tatort, da werden ja sozusagen
alle Ports gespiegelt und
beobachtet beobachtbar gemacht.
Und dadurch haben wir den Nachteil, dass
wir jetzt beispielsweise Clients, die im
WLAN hängen, die da können
wir nichts abfangen, da sehen wir nicht,
was da passiert wäre.
Wir müssen halt alles über die
Sehenswürdigkeiten.
Und jetzt gern Fragen.
Danke!
Wir haben eine ganze Menge Zeit für
Fragen
und so habt ihr Probleme
gesehen, dass der Switch zum Beispiel
bei höherer Pakete gedrückt hat oder
euer Monitor Server und es dadurch so
aussah, als ob ihr
Pakete hätte, 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 Melanom.
Tschuldigung, darf ich das sagen?
Wir haben relativ schnell es witzig
bekommen und
wir haben vorhin auch das Leid gehabt,
mit dem sie wie das endet.
Die Witze, die wir dann hatten, waren
hundert Gigabit Witze
und die waren auch von der
Performance ausreichend
schnell, um alle
Daten zu liefern, damit da nichts
auf dem Typekit auf dem Monitor 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 Clients hat und dann den
Datenverkehr bündelt auf einem
Typekit, dann kann
es natürlich sein, wenn er zu klein
dimensioniert ist, dass Pakete wegfliegen
kann auf dem Monitor, Server oder auch
einfach random, dass ein Paket, mit dem
andere Leute auch fragen
und das
andere Gruppe?
Gibt es eine Möglichkeit, den Buffer
der Netzwerkkarte auszulesen und zu
kontrollieren, ob da auch nur das
drinsteht, was Narayen geschrieben hat?
Dann könnte man das ganze doch lokal
machen, oder?
Ähm.
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 der Pakete, die
verarbeitet wurden, sofort
aus dem Speicher entfernt werden oder
in der Regel eigentlich werden, die
verarbeitet werden. Sobald ein Byte
gesendet wurde, ist es nicht mehr
interessant.
Netzwerk haben kann ich nicht genau
sagen, aber das ist natürlich auch
abhängig davon, was für ein Modell man
hat, also was der Hersteller und eben
auch was für Modell. Und das haben wir
glaube ich bei dieser
Forschungsarbeit gesehen, die vorhin
angesprochen habe von 2010 oder was mit
der Brotkorb Chip.
Diese Firma, die da geschrieben wurde,
funktionierte nur in einem bestimmten
Fall mit einer bestimmten Chipsatz,
weil natürlich sonst andere Register,
andere
CPU drin und
das ist schon sehr spezifisch.
Und genau das ist auch die Spezialität.
Weil wir uns halt so Hardware da
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 gut geht,
sondern es ist so schwierig zu erkennen,
weil die sich halt so unterscheiden und
spezialisiert sind auf die Hardware.
Und ja, das ist halt das Problem.
Das rechte Mikro bitte wieder,
um noch mal bei den Netzwerken quasi
zu bleiben, stellt
TCP auf Loading oder solche Netzwerk
Karten Funktionen Problem dar.
Ja, wenn man
nicht aufpasst. Genau am Anfang haben wir
schlicht vergessen, dass in der
App überall Müll drinsteht und haben uns
gewundert, warum das nicht funktioniert.
Weil eben diese
Treiber sehen wir natürlich noch keine
Checks und wenn die von der Netzwerkkarte
gebildet werden, zwei
Möglichkeiten oder mehrere Möglichkeiten.
Zum einen kann man das abschalten.
Das war der erste Lösung.
Zum anderen können wir tatsächlich im
Treiber auch
Statusmeldungen verschicken,
und zwar Filter.
UID Requests Sie wird sehr genau
das ist die Funktion, mit der wir
diese Funktion in der Netzwerkkarte ein
und ausschalten können.
Das wäre die zweite Möglichkeit.
Und die dritte Möglichkeit ist einfach,
entweder den Hash selber in Treiber zu
generieren.
Wir haben uns aber dazu entschieden
auf dem Monitor Server.
Wenn wir die Daten bekommen, bekommen wir
das ganze Paket mit
mit Jackson
rauszuholen und bei der Generierung
im Client auch egal ob da jetzt
Jackson kommen oder nicht, die
auch auszunutzen.
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
Speicher Block, also zwei,
drei Einträge
in so einer NDL und
müssten das dann zusammensetzen und
verstehen was da passiert. Und das ist
bei TCP IP nicht so komplex
oder sagen also so ein
IP Checks und TCP Checks
und das war's dann.
Oder vielleicht.
Aber dann ja genau.
Aber tatsächlich, das waren Probleme.
Jetzt wieder die andere Seite.
Hallo, könnte so ein
gut geht im nicht auch selbst diese
pessimistisches Insekten in den
Datenstrom und dann
fressen?
Genau,
wir haben ja noch das Leisten.
Danke schön für die Frage.
Ja, das ist ja der mittlere
Bummel unterdrückt.
Natürlich gibt
es sehr intelligente
Kids in Beirut. Jetzt aber die
Problematik damals als ich als
Menschen.
Sie haben quasi unlimitierte Ressourcen,
weil die können beliebig groß sein, die
kann man beliebig komplex machen.
Das geht jetzt. Mit einer Netzwerkkarte
würde ich das ausschließen.
Da ist nicht genügend Speicher, um sowas
zu implementieren.
Zum Beispiel braucht man wahrscheinlich
so ungefähr anderthalb Kilowatt Assembler
Code oder Maschine Code.
Und wenn halt kein Platz ist, dann kann
man keine Funktion
simulieren.
Das ist eine Brücke anders und
das war auch jetzt Teil.
Oder ist jetzt auch der in der
Entwicklung, die jetzt stattfindet, die
super interessant ist? Wie können wir
denn uns
in einem Antastet
wurde? In einem Bereich, den wir nicht
vertrauen?
Wie können wir das Vertrauen herstellen?
Nur für uns, für unsere Funktion?
Und da wir uns ein
paar stumpfe Sachen überlegt wir können
zum Beispiel alle zwei Wochen
mal den Treiber tauschen und dann nehmen
wir nicht die 5 zum Hash generieren,
sondern er hat C4.
Das sind alles wird benutzt.
Übrigens MD5.
Das ist aber bei uns überhaupt gar kein
Problem. Ich finde es ganz toll.
Es macht keine langen
Checks Summen und es ist ziemlich
schnell.
Die Problematik, dass es 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
eine Kollision bekommen, ist relativ
gering.
Deswegen ist es gut
für alle anderen Anwendungen.
Szenarien ist eigentlich nicht gut, das
möchte ich noch mal ausdrücklich
erwähnen.
Genau. Und das ist schon
etwas, worüber wir uns Gedanken gemacht
haben. Wie können wir das verhindern?
Und wenn wir jetzt zum Beispiel den
Treiber einfach tauschen?
Also wir lassen noch mal den Installations
Routine rennen und tauschen den Treiber
aus und dann sieht die Funktionsweise
auch anders. Und wir gucken, dass
die Abfolge der Pakete irgendwie
der der Funktionen anders ist.
Dann nachher die rauskommt, bekommen wir
ein anderes Produkt und wenn wir das
installieren,
dann würden wir jetzt im Moment noch
davon ausgehen, dass das Rukwied keine
Chance hat, sich darauf einzustellen
und erst mal den Betrieb einstellen muss.
Weil wenn es dann versucht,
eine neue Funktion herunterzuladen, um
auf dieses 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 performant rutschen, die wir da
zur Verfügung hatten.
Das ist seit Linux Switche.
Da kann man dann auch versuchen die
Hashes an einem Server
Monitor Server zu generieren.
Das kann man eigentlich im Switch machen.
Was weg um hier
die Slide zu vervollständigen.
Rechts bitte.
Vielleicht wegen dem Problem?
Ich glaube das könnte ja prinzipiell
nicht lösen, oder?
Ich meine, wenn
ihr ein Roadkill drauf habt, wie wollt
ihr sicherstellen, dass euer Client
nicht lügt gegenüber einem System?
Genau das ist genau die Frage,
die wir haben. Und klar, es
gibt keine sichere Lösung, aber
was wir bisher gesehen haben ist
das.
Es gibt schon relativ komplex ist, aber
ich glaube, es war
ziemlich komplex, was so was angeht.
Die waren wirklich dann auf dieses
Szenario hin gebaut, wo sie eingesetzt
wurden oder da die Software.
Und wenn. Wenn man mit sowas konfrontiert
ist, ist es immer schwer. Aber die große
Lösung war einfach. Zum Beispiel, dass
eben da die die Funktionsweise
des Programmes zu tauschen.
Und zwar in einer Form, die nicht
vorhersagbar ist.
Also wir können einfach
zwei Bilder machen, halt erst mal die
500er C4 und zwei Monate später als
ihr danach MD5 oder was auch einfach
ein bisschen unvorhersehbar sein.
Und dann muss man halt die die menschliche
Komponente reinbringen.
Das kann man maschinell nicht lösen,
dieses Problem.
Und die letzte Frage, die ich sehe
Habt ihr euch im Rahmen eurer Arbeit auch
mit Hardware Security Elementen sozusagen
auseinandergesetzt, seit dem begegnet?
Ich habe dich nicht verstanden.
Die Frage Entschuldigung, seid ihr im
Rahmen eure Arbeit auch Hardware Security
Elementen begegnet, die sozusagen schon
in die CPU mit reinkommen?
Dass die Intel
TX zum Beispiel
in Form von IBM Hardware
Security Animate, wie zum Beispiel einen
TPM und Trusted Platform Modul
ist das Thema gewesen,
weil diese das soll er genau dieses
Problem lösen, das man sozusagen
ab dem Boten sozusagen wenn man Hash
Werte bilden kann und diese sogenannte
Picards rein schreibt und dann sozusagen
Skorbut Chain aufbauen zu können.
Das Problem bei TPM ist,
wenn ich das richtig weiß
das TPM
davon ausgeht, dass das BIOS und
auch das BIOS vertrauenswürdig
ist und.
Äh, ja, das ist eine
gute Frage.
Da müsste jetzt vielleicht auch noch
drüber nachdenken, aber
kann man es nicht auch noch mal haben?
Dann sprechen wir aber später noch mal
drüber.
Aber um deine Frage zu beantworten
wir haben uns noch nicht so wirklich
viele Gedanken gemacht.
Gut, ich sehe keine weiteren
Fragen und das war's dann.
Vielen Dank für einen Vortrag.
Und falls ihr doch noch Fragen
habt, dann könnt ihr sicherlich im Laufe
des Abends noch auf sie
zukommen. Und
vielen Dank
für eure ActionScript.