WEBVTT

00:00.000 --> 00:10.700
Ja, dann herzlich willkommen zum zweiten Vortrag heute beim Security Day.

00:11.740 --> 00:21.380
Ich stehe hier jetzt gerade, weil ich den Herrn Dr. Duplis eingeladen habe vom Bosch Forschungszentrum in Renningen.

00:22.600 --> 00:29.120
Ich kenne den Herrn Dr. Duplis, weil wir vor zwei Jahren mal gemeinsam eine Bachelor-Thesis betreut haben

00:29.120 --> 00:31.960
aus dem Thema IoT Security.

00:33.040 --> 00:36.220
Und ja, das war eine sehr schöne Zusammenarbeit

00:36.220 --> 00:39.820
und ich freue mich sehr, dass da meine Einladung gefolgt ist.

00:39.940 --> 00:45.240
Und heute stellt er einen sehr interessanten neuen Forschungsansatz vor,

00:45.240 --> 00:52.700
der eben hoffentlich auch dann mündet in gemeinsame Bachelor- und oder Masterthesen.

00:53.140 --> 00:56.940
Also ich bin sehr gespannt und freue mich sehr auf den Vortrag.

00:59.120 --> 01:14.400
Vielen Dank für die Vorstellung. Ich freue mich hier zu sein. In meinem Vortrag geht es um Vulnerability Mining in Software mit einem Tool namens Yorn.

01:14.400 --> 01:37.460
Das ist jetzt nichts, was wir bei Bosch entwickelt haben. Das wurde von Yamaguchi, Golde, Arp und Rieck 2014 auf der S&P vorgestellt und wir schauen uns den Ansatz an bzw. gucken uns, wie wir das einsetzen können.

01:38.360 --> 01:39.460
Sollen wir eine kurze Pause machen?

01:44.400 --> 01:46.640
Alles klar.

01:50.060 --> 02:00.420
Kurz zu meiner Person. Ich bin Sicherheitsforscher bei der Robert-Bosch-GmbH. Ich sitze in Renning, in dem neuen Research Campus.

02:01.740 --> 02:05.720
Ich bin Teil des Kompetenzsegments Safety, Security and Privacy.

02:07.180 --> 02:12.760
Das ist eigentlich interessant, was der Professor Kriha schon erzählt hat.

02:12.760 --> 02:37.160
Man sieht, dass auch bei uns diese Themen wie Robustheit und Security zusammenwachsen an der Stelle. Ich bin im Bereich Security Research ungefähr seit zehn Jahren unterwegs, habe da verschiedene Themen mitgemacht, Krypto-Hardware gebaut, Seitenkanalangriffe gemacht oder mich mit den Gegenmaßnahmen beschäftigt.

02:37.160 --> 02:41.040
Physical Layer Based Security

02:41.040 --> 02:44.740
gemacht. Das ist das, was Professor Schmitz

02:44.740 --> 02:48.280
angesprochen hat, was zu dem Thema

02:48.280 --> 02:50.680
Physical Unloadable Functions gemacht.

02:51.900 --> 02:53.860
Jetzt haben wir wieder ein Bild, perfekt.

02:56.140 --> 03:00.680
Seit einiger Zeit gucke ich mir Software Security an

03:00.680 --> 03:04.460
und nur als kleine Motivation,

03:04.460 --> 03:24.240
Warum Software Security? Naja, bei uns ist es ganz klar, dass Security hauptsächlich dadurch motiviert ist, dass die Konnektivität in den Systemen zunimmt. Da ist jetzt, sagen wir mal, ein modernes Fahrzeug auch ein sehr gutes Beispiel. Auch was Professor Kriha in dem einleitenden Vortrag gezeigt hat.

03:24.240 --> 03:32.820
und natürlich wenn ich über Netzwerk remote was angreife, dann ist Software einfach die Ebene schlechthin, die da exponiert ist.

03:34.420 --> 03:41.480
Bevor ich jetzt weitergehe, kurz zu dem Fahrplan, ich werde den Vortrag zeigen, dann mache ich eine kurze Pause,

03:41.980 --> 03:48.200
dann baue ich meinen zweiten Rechner auf und dann kann ich ein bisschen live zeigen, wie man mit dem Tool umgeht und was man damit machen kann.

03:48.200 --> 03:57.380
Okay, ja, ich glaube, ich muss jetzt hier niemandem erzählen, was Hardbleed ist.

03:57.380 --> 04:01.880
Deswegen gehen wir gleich weiter.

04:01.880 --> 04:14.480
Im Endeffekt ein typischer Fall für solche Schwachstellen, also solche Taint Style Vulnerabilities,

04:14.480 --> 04:38.520
dass der Input vom Benutzer oder was auch immer ins System reinkommt, praktisch nicht überprüft wird, nicht sanitized wird und dann in solchen Funktionen wie Memcpy, das ist jetzt im Fall von Heartbleed, verwendet wird, ohne eine vernünftige Validierung gemacht zu haben,

04:38.520 --> 04:48.600
was dann zu solchen Problemen führt, wie damals bei Hardbleed, dass eben da riesige Speicherbereiche dann zum Beispiel rausgelegt werden und rauskopiert werden.

04:51.360 --> 05:04.320
Und die Frage ist, wie kann man jetzt solche Schwachstellen und vielleicht auch teilweise so klassische Buffer-Overflows entdecken.

05:04.320 --> 05:20.720
Das ist, sage ich jetzt mal, auch die Frage für uns im Bereich Security Research bei Bosch. Und da gab es eben 2014 diesen Ansatz, den Yamaguchi et al. präsentiert haben.

05:20.720 --> 05:29.960
Und da ist die grundlegende Idee, dass man im Grunde genommen aus dem Quellcode diese drei Arten von Graphen zunächst mal ableitet.

05:30.620 --> 05:41.240
Also den Abstract Syntax Tree, das sieht man oben mit rechter Hand, den Control Flow Graphen, der dann praktisch den Control Flow von dem Programm beschreibt,

05:41.240 --> 05:47.280
und den Data Dependency Graphen, der dann die entsprechenden Abhängigkeiten zwischen den Daten beschreibt.

05:47.280 --> 05:53.220
und dann diese Graphen im Prinzip merged.

05:54.580 --> 06:00.140
Das heißt, unter jedem Knoten von dem Control-Flow-Graphen,

06:00.180 --> 06:05.260
unter jedem Statement, kann ich eben so ein ISD-Subtree aufhängen

06:05.260 --> 06:12.080
und kann das Ganze dann nochmal mit dem Program-Dependency-Graph kombinieren.

06:12.080 --> 06:21.060
Und was man dann erhält, ist eben so ein kombinierter, gemergeder Graph im Prinzip.

06:21.900 --> 06:33.220
Und die Idee von Yamaguchi Yatel war jetzt, Software-Schwachstellen als Suchen in diesem Graphen zu definieren

06:33.220 --> 06:36.960
und praktisch automatisiert das abzufragen.

06:36.960 --> 06:41.880
und im Grunde genommen

06:41.880 --> 06:43.740
was die gemacht haben ist

06:43.740 --> 06:45.700
aus meiner Sicht eine clevere

06:45.700 --> 06:47.040
Sache

06:47.040 --> 06:48.960
die haben im Grunde genommen

06:48.960 --> 06:51.980
Datenbanken, grafenbasierte Datenbanken

06:51.980 --> 06:52.420
genommen

06:52.420 --> 06:55.280
diese Datenbanken

06:55.280 --> 06:57.480
diese Grafen

06:57.480 --> 06:59.820
die entsprechend ausgedrückt

06:59.820 --> 07:01.660
und dann

07:01.660 --> 07:03.600
in so eine grafenbasierte

07:03.600 --> 07:05.500
Datenbank konkret ist das

07:05.500 --> 07:06.260
Neo4j

07:06.260 --> 07:09.740
reingesteckt und jetzt kann man quasi damit

07:09.740 --> 07:14.720
solche Queries definieren. Also man kann die Queries sich vorstellen,

07:14.820 --> 07:18.440
ich zeige es nachher auch, ähnlich wie Queries jetzt in

07:18.440 --> 07:22.440
irgendeine SQL-Datenbank, nur dass ich eben irgendwie einen Graphen traversiere

07:22.440 --> 07:25.960
mit den Queries. Und

07:25.960 --> 07:30.300
oben ist so ein Beispiel für so ein

07:30.300 --> 07:33.540
Query gezeigt. Im Grunde genommen wird dort

07:33.540 --> 07:37.760
nach Aufrufen von dieser MemCopy-Funktion gesucht,

07:38.280 --> 07:42.280
dann werden quasi in dem zweiten TaintedArgs, das ist so eine Art

07:42.280 --> 07:46.280
Filter, wird alles gesucht, was von diesen N2S-Funktionen

07:47.200 --> 07:50.140
Makros kommen, weil man eben

07:50.140 --> 07:54.540
jetzt speziell für OpenSSL weiß, dass es Funktionen

07:54.540 --> 07:57.840
sind, wo, also es ist N2S steht, Network to System,

07:58.540 --> 08:02.240
für Payload, wo ihr irgendwo aus dem Netzwerk kommt, und

08:02.240 --> 08:12.160
Und dann werden einfach mit dem letzten Filter, mit diesem Unchecked, werden eben alle Knoten gesucht, wo quasi diese Angaben nicht sanitized wurden.

08:12.160 --> 08:27.440
Und so kann ich im Grunde genommen in einer großen Code-Basis relativ schnell mich bei der Suche auf die wesentlichen Stellen einschränken, wo Fehler eben sehr wahrscheinlich sind.

08:27.780 --> 08:30.560
Also das ist sozusagen die Grundidee.

08:30.560 --> 08:50.100
Und die zweite Idee, die im Grunde genommen recht naheliegend ist, ist eben für diese Traversierung, die so klassische Schwachstellen beschreiben, quasi Templates zu bauen, also im Grunde genommen solche generischen Queries.

08:50.100 --> 09:01.680
Und diese Queries dann irgendwo zentral in der Datenbank irgendwo zu speichern und dann praktisch jedes neue Softwareprojekt einfach dagegen zu prüfen.

09:01.680 --> 09:02.960
Genau.

09:02.960 --> 09:14.600
Genau. Und hier sieht man als Beispiel so eine Query für Hardbleed.

09:15.500 --> 09:23.560
Oder klar, oben sieht man, dass man das für alle Taint-Style-Vulnerabilities generalisieren kann.

09:24.740 --> 09:28.460
Und hier ist eben das, was ich vorhin schon erwähnt habe.

09:28.460 --> 09:37.640
Im Grunde genommen suche ich erstmal alle Knoten in der Grafendatenbank, die eben Aufrufe von MemCopy repräsentieren.

09:37.640 --> 09:44.440
Und dann filtere ich die entsprechend, dass ich da nur Argumente aus den N2S-Makros habe.

09:44.960 --> 09:50.540
Und zum Schluss gucke ich nochmal, ob für diese Aufrufe die Argumente sanitized wurden oder nicht.

09:50.540 --> 10:11.700
Jetzt muss man sagen, wo da quasi die Magie passiert, ist diese Get Calls To und Tainted Hacks und so, das sind sogenannte Yarn Steps, das ist quasi so eine Abstraktionsschicht, die es da in dem Tool gibt.

10:11.700 --> 10:36.800
Die kann man aber auch selber sich zusammenbauen und die basieren einfach darauf, dass die Datenbank nach den entsprechenden Knoten und Kanten durchgehen und die Attribute von diesen jeweiligen Knoten und Kanten auswerten und quasi eine Semantik definieren, was ist jetzt für mich Dainted Arc oder was bedeutet für mich jetzt Sanitized oder nicht Sanitized.

10:36.800 --> 10:58.980
Genau. Und das jetzt jedenfalls aus meiner Sicht nette ist, dass die Jungs nicht nur sich eine schicke Methodik irgendwo überlegt haben und das auf einem Papier aufgeschrieben haben, sondern auch tatsächlich da ein Tool gebaut haben und das auch open sourced haben.

10:58.980 --> 11:06.220
Man kann das auf GitHub runterladen bzw. auschecken.

11:07.880 --> 11:17.780
So als Überblick, wie schon erwähnt, da zugrunde liegt diese Neo4j-Grafendatenbank, was die verwenden.

11:17.780 --> 11:28.660
Da gibt es verschiedene Templates, um zunächst mal verschiedene Schritte zu bauen bzw. verschiedene Schwachstellen zu finden.

11:28.980 --> 11:41.680
Und es wurde in Zusammenarbeit mit Qualcomm und IBM zumindest auch an realistischen Softwareprojekten getestet und das mit großem Erfolg. Das zeige ich gleich.

11:41.680 --> 11:44.120
genau

11:44.120 --> 11:47.020
die haben damals das

11:47.020 --> 11:49.760
2014 auf dem

11:49.760 --> 11:52.200
Linux-Körnel getestet

11:52.200 --> 11:53.580
und haben

11:53.580 --> 11:55.840
in dem Paper

11:55.840 --> 11:57.820
was ich da zitiert habe

11:57.820 --> 11:59.680
sind die Queries nochmal genauer

11:59.680 --> 12:01.720
aufgeführt, die hatten zwei

12:01.720 --> 12:03.700
Queries zu Buffoverflows

12:03.700 --> 12:04.720
und haben

12:04.720 --> 12:07.580
sieben Zero Days in

12:07.580 --> 12:08.560
elf Hits

12:08.560 --> 12:10.700
quasi rausbekommen

12:10.700 --> 12:36.760
Und die nette Sache hier ist natürlich, ich meine in der Theorie ist es natürlich fantastisch, wenn ich irgendwelche Methoden habe, die quasi komplett sind, die mir alle möglichen Schwachstellen liefern, aber solche Methoden haben halt das Problem, dass ich in der Praxis dann 50.000 Fehlermeldungen habe und dann jedes einzelne durchgehen muss.

12:36.760 --> 13:05.860
Und das ist natürlich, das ist einfach vom Aufwand her und von Cost-Benefit extrem schwer in der Praxis und in der Wirtschaft darzustellen. Und wenn ich jetzt natürlich was habe, was vielleicht nicht alle Schwachstellen raussucht, wo ich aber mit ziemlich großer Sicherheit sagen kann, okay, das, was mir das Tool meldet, ist wahrscheinlich auch eine Schwachstelle, ist sehr vorteilhaft an der Stelle.

13:06.760 --> 13:14.760
Insgesamt wurden da wie da schon drauf steht 18 Zero-De-Vulnerabilities gefunden.

13:14.760 --> 13:22.760
Dann haben die das auch noch auf so einem proprietären Qualcomm Code sich angeschaut.

13:22.760 --> 13:31.760
Ich meine eine mögliche Schlussfolgerung hier wäre, dass man kein proprietäres Code benutzen sollte.

13:31.760 --> 13:33.860
Also 100 Schwachstellen, das ist schon heftig.

13:35.880 --> 13:40.880
Und das letzte Ergebnis, das ist von 2015.

13:41.540 --> 13:45.160
Das ist im Prinzip auch eine interessante Richtung.

13:45.160 --> 13:53.340
Die haben sich angeschaut, wie man mit Machine Learning Methoden Programme so leisten kann,

13:53.880 --> 13:58.160
dass man diese Vulnerabilities automatisiert, identifiziert,

13:58.160 --> 14:04.600
beziehungsweise dass man quasi mit Machine Learning die Queries automatisch generiert.

14:04.600 --> 14:27.780
Und dann wurde da an diesen vier Softwareprodukten, also Linux Kernel, OpenSSL, Pidgin und der VLC Player, wurde so ein kontrolliertes Experiment durchgeführt und die konnten tatsächlich mit diesen automatisch generierten Queries die entsprechenden Bugs finden.

14:28.160 --> 14:43.520
Also so sieht im Prinzip dann das Setup aus, beziehungsweise dann die Vision, dass man eben so eine Analyseplattform hat

14:43.520 --> 14:51.520
und quasi aus dem Code wird mit Machine Learning dann die entsprechenden Queries generiert, die da auf die Schwachstellen hinweisen

14:51.520 --> 14:59.740
hinweisen und dass der Mensch quasi, ich sage mal, nur noch die Maschine mehr oder minder fragen soll,

15:00.140 --> 15:04.540
hey, welche Queries soll ich mal absetzen, um zu schauen, ob ich da Probleme habe.

15:06.040 --> 15:14.940
Ich persönlich finde den Ansatz auch sehr interessant, weil natürlich wir haben mittlerweile so viel Software

15:14.940 --> 15:21.960
und alles, was ich irgendwie automatisiert abfrühstücken kann, das ist unheimlich sympathisch.

15:23.420 --> 15:31.320
Genau, das ist so ein kurzer Überblick zu dem Tool und zu dem Thema.

15:33.120 --> 15:38.020
Und wie Professor Schmitz schon in der Vorstellung angedeutet hat,

15:38.160 --> 15:43.620
wir suchen natürlich immer motivierte Studenten, die Interesse haben,

15:43.620 --> 15:51.240
sich mit dem Thema Software-Sicherheit an sich, aber auch speziell mit diesem Thema zu beschäftigen.

15:51.940 --> 15:57.140
Und wer Interesse hat, einfach mich ansprechen oder eine E-Mail schreiben oder mich anrufen.

15:58.460 --> 16:04.580
Und wir haben im Prinzip Praktika, Bachelorarbeiten, Masterarbeiten anzubieten.

16:05.120 --> 16:06.100
Genau. Vielen Dank.

16:13.620 --> 16:26.560
Vielen Dank.

16:43.620 --> 17:03.420
Okay.

17:03.420 --> 17:03.600
Okay.

17:05.640 --> 17:06.560
Genau.

17:07.440 --> 17:09.540
Ich habe mal für die Demo

17:09.540 --> 17:11.260
ein bisschen was

17:11.260 --> 17:12.820
auf die Schnelle

17:12.820 --> 17:14.940
zusammengeschrieben. Das ist

17:14.940 --> 17:17.420
ein Bug

17:17.420 --> 17:20.300
in der 0.9.4

17:20.300 --> 17:21.160
Version von dem

17:21.160 --> 17:22.020
VLC Player.

17:24.540 --> 17:25.380
Ich weiß nicht,

17:26.000 --> 17:26.060
ob

17:26.060 --> 17:29.200
manchen von euch

17:29.200 --> 17:29.900
dieses Buch

17:29.900 --> 17:33.480
Bug Hunters Diary bekannt ist.

17:33.480 --> 17:35.020
Da wird zum Beispiel das auch

17:35.020 --> 17:35.800
beschrieben.

17:37.260 --> 17:37.780
Okay.

17:39.600 --> 17:41.580
Es handelt sich dort im Prinzip

17:41.580 --> 17:43.860
auch um so eine Art

17:43.860 --> 17:45.440
Taint-Style Vulnerability

17:45.440 --> 17:47.660
ist es ein klassischer Buffer-Overflow

17:47.660 --> 17:49.080
im Prinzip wird da

17:49.080 --> 17:51.300
in

17:51.300 --> 17:53.460
dem Quellcode, in dem

17:53.460 --> 17:55.900
D-Maxer von dem VLC-Player

17:55.900 --> 17:57.300
wird

17:57.300 --> 17:59.600
quasi ein Wert

17:59.600 --> 18:01.900
aus der Datei

18:01.900 --> 18:03.420
genommen, das als

18:03.420 --> 18:05.520
Längeangabe interpretiert und

18:05.520 --> 18:07.440
dann werden halt so viele Bytes in ein Buffer

18:07.440 --> 18:09.640
kopiert, natürlich

18:09.640 --> 18:11.200
ohne Sanitizing, das heißt

18:11.200 --> 18:13.100
wird einfach nicht überprüft, ob

18:13.100 --> 18:15.680
dieser Wert tatsächlich in einem bestimmten Range ist.

18:16.540 --> 18:16.740
Und

18:16.740 --> 18:19.880
jetzt können wir mal versuchen,

18:20.680 --> 18:21.000
quasi

18:21.000 --> 18:22.720
ein bisschen nachzustellen,

18:23.160 --> 18:25.420
wie man das mit Ion

18:25.420 --> 18:26.600
finden kann.

18:28.560 --> 18:29.520
Vielleicht können wir

18:29.520 --> 18:31.120
jetzt doch dieses

18:31.120 --> 18:33.520
andere Mikro nehmen, weil ich muss ein bisschen tippen.

18:34.040 --> 18:35.460
Deswegen wird es

18:35.460 --> 18:36.980
wahrscheinlich ein bisschen blöd sein mit dem.

18:41.200 --> 19:00.020
Ja, perfekt.

19:01.360 --> 19:03.320
Kann man mich hören? Prima.

19:04.380 --> 19:04.960
Okay.

19:06.820 --> 19:08.400
Als erstes

19:08.400 --> 19:13.360
so muss ich rausfinden, wo jetzt meine Maus verschwunden ist

19:13.360 --> 19:16.400
sieht gut aus

19:27.840 --> 19:30.920
jetzt starte ich mal den Server

19:30.920 --> 19:33.920
für die Neo4j Datenbank

19:33.920 --> 19:37.580
ich hoffe, dass es nicht zu lang dauert

19:37.580 --> 19:45.740
wunderbar und im Prinzip diese Datenbank ist dann unter localhost 74 74 erreichbar.

19:47.740 --> 19:52.700
Wir können spaßeshalber, wenn ich die Maus finde,

19:54.280 --> 20:01.680
das ist natürlich ein bisschen elend, mal reinschauen, wie das dann in Rohform quasi aussieht.

20:04.100 --> 20:05.260
Kleinen Moment.

20:07.580 --> 20:17.300
So, kann ich das jetzt verschieben hier?

20:23.540 --> 20:30.520
Genau, also das ist im Grunde genommen eine Web-Oberfläche für die Neo4j-Datenbank.

20:30.880 --> 20:33.400
Ich habe da den Quellcode schon importiert.

20:33.400 --> 20:47.380
Was in dem Yorn-Tool verwendet wird, ist so ein robuster CAC++-Parser und da ist halt das Nette, dass man auch quasi Code analysieren kann, der noch nicht komplett kompilierfähig ist.

20:47.380 --> 20:54.220
Also ich kann einfach den mit dem Parser entsprechend importieren und in diese Darstellung bringen.

20:54.220 --> 20:57.700
jetzt, also das ist quasi

20:57.700 --> 21:03.020
da sieht man so ein bisschen wie das aufgebaut ist

21:03.020 --> 21:05.840
also dieses Stern ist quasi der Root Node

21:05.840 --> 21:11.940
und die ganzen Knoten, die da in die Datenbank importiert werden

21:11.940 --> 21:15.800
man sieht, die haben quasi gewisse Attributen

21:15.800 --> 21:20.160
je nachdem, ob das jetzt ISD Nodes sind

21:20.160 --> 21:25.140
oder CFG oder Data Dependency Graph

21:25.140 --> 21:29.060
und die ganzen Kanten haben quasi auch diese Benamung,

21:29.560 --> 21:33.440
also ist ist, parent, von, bla und so weiter.

21:34.320 --> 21:38.540
Und diese High Level Steps, die man vorhin gesehen hat,

21:39.000 --> 21:43.260
die sind so aufgebaut, dass man quasi durch den Graphen durchgeht

21:43.260 --> 21:47.200
und dann immer guckt, welche Kanten und welche Knoten man nehmen muss

21:47.200 --> 21:49.680
und quasi die rausschmeißt, die man nicht braucht.

21:49.680 --> 21:52.680
und dann kommen wir auf so eine kompakte Menge quasi.

21:54.200 --> 22:01.460
Und das ist auch alles Python, deswegen kann man im Grunde genommen das Ganze auch skripten.

22:01.460 --> 22:06.420
Aber jetzt für die Demo machen wir das ein bisschen anders.

22:07.460 --> 22:14.920
Also zunächst mal können wir uns anschauen, ob wir sehen, ob wir die Funktion finden.

22:14.920 --> 22:19.820
das ist natürlich extrem

22:19.820 --> 22:22.420
schlecht, dass ich hier die Maus nicht sehe

22:22.420 --> 22:33.800
also es gibt quasi auch so

22:33.800 --> 22:36.680
Command Line Tools quasi

22:36.680 --> 22:39.860
im Grunde genommen ist das auch nur

22:39.860 --> 22:41.620
nur Python

22:41.620 --> 22:44.540
und jetzt kann ich so zum Beispiel

22:44.540 --> 22:48.280
alle Aufrufe von dieser StreamRead-Funktion.

22:48.400 --> 22:51.620
Das ist die Funktion, die da an der Stelle

22:51.620 --> 22:56.460
eben quasi aus den Input-Daten liest.

22:57.560 --> 23:01.380
Und was wir machen können,

23:01.500 --> 23:04.660
um jetzt wirklich die Schwachstelle

23:04.660 --> 23:08.860
uns anzuschauen,

23:14.540 --> 23:27.400
mit diesem YonLocation

23:27.400 --> 23:29.700
kann ich mir quasi das Mapping

23:29.700 --> 23:30.520
ausgeben

23:30.520 --> 23:34.220
in welche Datei

23:34.220 --> 23:35.800
welcher Knoten steckt

23:35.800 --> 23:37.500
und

23:37.500 --> 23:40.140
ich weiß jetzt, dass es in

23:40.140 --> 23:41.960
ty.c

23:41.960 --> 23:44.020
sein muss

23:44.020 --> 23:52.600
Deswegen können wir uns anschauen, ob der das auch findet, Source Modules, D-MAX, genau.

23:52.600 --> 23:57.700
Ich versuche mal die Datei einfach aufzumachen.

23:57.700 --> 24:12.980
Was ist jetzt passiert?

24:27.700 --> 24:41.160
Tja.

24:41.160 --> 24:59.940
Das ist natürlich sehr schlecht zu sehen.

24:59.940 --> 25:02.500
Das war eine schlechte Idee, das zu zeigen.

25:06.780 --> 25:08.400
Nehmen wir das mal einfach weg.

25:11.160 --> 25:18.780
Was ich jetzt quasi machen kann, wenn ich jetzt nach dieser Schwachstelle suche,

25:18.780 --> 25:42.840
Ich kann jetzt einen Lookup machen, was mir jeweils das dritte Argument,

25:42.840 --> 25:48.660
was die StreamRead-Funktion benutzt, ausgibt.

25:48.820 --> 25:54.680
Also das sind quasi die Argumente in dem gesamten Quellcode verteilt

25:54.680 --> 26:01.000
und kann mich dann anfangen und von diesem dritten Argument,

26:01.080 --> 26:06.240
weil ich weiß, dass es die Größenangabe ist, mich rückwärts durchtraversieren.

26:06.560 --> 26:10.720
Und natürlich würde ich jetzt, wenn ich das automatisieren würde,

26:10.720 --> 26:15.340
quasi ein Python-Skript schreiben, wo ich für jedes Argument diese Auswertung mache.

26:20.920 --> 26:30.100
Was man quasi rausbekommen würde, wenn man jetzt für jedes Argument das macht,

26:30.100 --> 26:38.100
also ich mache das jetzt hier quasi um zu veranschaulichen für das IMAP-Size,

26:38.100 --> 26:43.440
Das wäre halt eins von diesen Argumenten, die da rausgespuckt wurden.

26:44.100 --> 26:55.160
Und so kann man im Grunde genommen eine Query laufen lassen, wo man einfach sieht, wo man einen Verweis auf das entsprechende Symbol im Quellcode bekommt.

26:55.160 --> 26:59.900
wenn ich das Symbol habe

26:59.900 --> 27:04.280
dann würde ich quasi als nächstes

27:04.280 --> 27:06.660
wie gesagt alles

27:06.660 --> 27:09.900
dann im entsprechenden Python-Skript automatisiert

27:09.900 --> 27:12.800
im Grunde genommen so eine Query laufen lassen

27:12.800 --> 27:16.920
wo ich nach allen Assignment-Expressions suche

27:16.920 --> 27:20.480
und das ist halt jetzt das, was in dem ISD vorkommt

27:20.480 --> 27:23.400
wo eben dieses Symbol verwendet wird

27:23.400 --> 27:28.620
da komme ich eben auf dieses U32

27:28.620 --> 27:30.200
AT-Makro

27:30.200 --> 27:32.840
hier wird im Grunde genommen

27:32.840 --> 27:33.760
an der Stelle

27:33.760 --> 27:36.680
aus diesem MST-Buffer

27:36.680 --> 27:39.000
quasi die Größe

27:39.000 --> 27:41.360
von dem zu kopierenden

27:41.360 --> 27:42.920
Payload dann in die

27:42.920 --> 27:44.620
IMAP-Size kopiert

27:44.620 --> 27:46.940
und so kann ich

27:46.940 --> 27:48.300
mich zurückarbeiten

27:48.300 --> 27:50.000
wenn ich jetzt die

27:50.000 --> 27:51.820
entsprechende

27:51.820 --> 27:54.080
das MST-Buffer

27:54.080 --> 27:55.640
gefunden habe.

28:16.040 --> 28:17.600
Kann ich entsprechend

28:17.600 --> 28:19.320
das MST-Buffer

28:19.320 --> 28:20.480
quasi raussuchen.

28:20.480 --> 28:26.840
Also das, was man vorne sieht, diese N und sowieso, das sind die IDs von den Knoten in der Datenbank.

28:26.960 --> 28:33.140
Ich kann die ja so eindeutig quasi adressieren und dann von dort aus zum Beispiel suchen, starten

28:33.140 --> 28:44.660
und kann entsprechend dann diesen Use von dem MS-Debuff,

28:44.660 --> 28:54.120
beziehungsweise wo der entsprechend mit Daten befüllt wird, ebenfalls quasi pro Funktion raussuchen.

28:54.700 --> 29:03.020
Und diese PathMaster-Funktion, das ist genau die Funktion, wo quasi dieser Fehler auftritt.

29:04.000 --> 29:15.920
Das heißt, die Methode hier ist, dass ich jetzt quasi diese ganzen Queries in ein Skript, in eine Datei stecke

29:15.920 --> 29:21.340
und einfach alle solche Stellen durchgehe und dann werde ich auf ein paar wenige hingewiesen.

29:22.340 --> 29:25.360
Und die muss ich natürlich mir manuell anschauen.

29:25.360 --> 29:33.480
Was natürlich die Methode erfordert, ist, dass man sich mit der Codebase ein bisschen vertraut gemacht hat,

29:33.800 --> 29:45.160
weil man hat das gesehen bei Heartbleed, man muss halt wissen, dass diese N2S-Makros eben Netzwerk nach System konvertieren,

29:45.300 --> 29:52.460
beziehungsweise hier, dass ich eben mit dieser Funktion StreamRead die Eingaben, also die Dateien quasi lese.

29:52.460 --> 30:04.100
Genau. Das wäre es soweit von meiner Seite. Wer noch Fragen hat oder so, ich bin noch eine Weile da. Vielen Dank.

30:08.300 --> 30:12.260
Zeit für Fragen. Wie sieht es aus? Wer hat eine Frage?

30:12.260 --> 30:21.000
Es gibt ja in dem Bereich diverse Werkzeuge, um Schwachstellen in Quelltexten zu finden.

30:21.420 --> 30:27.020
Eben auch von der IBM, die Sie eben schon erwähnt haben, das App-Scan-Tool wäre da so ein Beispiel, was zwar recht teuer ist,

30:27.560 --> 30:32.700
aber da bekomme ich dann auch in eine IDE integriert schon solche Scan-Funktionen,

30:32.700 --> 30:38.160
wo ich dann auch den Kontrollflussgraf, Datenflussgraf sehen kann und sehe, hier vorne war eine Eingabe,

30:39.060 --> 30:42.780
Hinten verwende ich sie irgendwo und zwischendrin ist eben keine Prüfung erfolgt.

30:42.860 --> 30:47.380
Da werden auch ähnliche Datenstrukturen natürlich aufgebaut und Prüfungen durchgeführt.

30:48.400 --> 30:55.460
Welchen Mehrwert hätte denn jetzt dieses Werkzeug hier gegenüber den Standard-Tools, die es da schon auf dem Markt gibt?

30:55.460 --> 31:10.920
Gut, zunächst mal muss man sagen, ich komme von der Forschung. Was die Kollegen in den Produktbereichen einsetzen, ist nochmal eine andere Sache.

31:10.920 --> 31:15.980
Also unser Auftrag ist, uns neue Sachen, andere Sachen anzuschauen.

31:18.500 --> 31:26.940
Grundsätzlich, da das hier Open Source ist und ich quasi die Suchanfragen für mich manuell entsprechend tunen kann,

31:28.020 --> 31:36.780
kann es für mich Vorteile bieten, wenn ich zum Beispiel jetzt Applikationscodes für ganz, ganz bestimmte Geräteklassen habe.

31:36.780 --> 31:54.120
Also da ist eben die Frage, wie gut ich mit diesen Tools, die vielleicht eher aus dem IT-Bereich kommen oder die eben von solchen Anbietern wie IBM oder wie die alle heißen, kommen, wie gut ich da tatsächlich solche Nischenbedürfnisse treffe.

31:54.120 --> 32:01.200
Und natürlich ist das jetzt auch bei uns Gegenstand der Untersuchung.

32:01.340 --> 32:07.960
Also ich kann jetzt nicht die endgültige Antwort liefern und ich hoffe, dass wir jetzt im Laufe der Zeit,

32:08.040 --> 32:14.060
wo wir uns mit der Methode, mit dem Tool beschäftigen, auch solche Vor- und Nachteile klären können.

32:24.120 --> 32:31.780
Ich würde noch einmal eine Sache nachfragen.

32:32.760 --> 32:36.400
Sie hatten ja eben auch das Thema Machine Learning in dem Zusammenhang angesprochen

32:36.400 --> 32:39.700
und ich denke, das wäre jetzt vielleicht auch so ein Unterscheidungsmerkmal

32:39.700 --> 32:42.320
zu diversen aktuellen kommerziellen Produkten,

32:42.320 --> 32:46.340
die halt nach wahrscheinlich eher festcodierten Logiken derzeit arbeiten

32:46.340 --> 32:51.320
und hier hätten Sie jetzt halt die Möglichkeit, noch eigene Erweiterungen einzubauen

32:51.320 --> 32:53.340
einzubauen und sozusagen Anfragen

32:53.340 --> 32:55.560
selbst zu generieren, die jetzt für ihren Anwendungsfall

32:55.560 --> 32:57.300
besser passen. Das wäre jetzt halt vielleicht

32:57.300 --> 32:59.460
so ein Vorteil vom Open Source

32:59.460 --> 33:00.820
Ansatz hier und von diesem Tool, oder?

33:01.380 --> 33:02.820
Genau, beziehungsweise

33:02.820 --> 33:05.120
ich sage mal ganz klar, es ist

33:05.120 --> 33:07.100
ein Anwendungsfall, wenn ich jetzt

33:07.100 --> 33:09.040
für meine

33:09.040 --> 33:10.960
spezielle Software oder meine

33:10.960 --> 33:13.040
Produktpalette quasi in der

33:13.040 --> 33:15.420
Datenbank von solchen Queries aufbauen kann,

33:16.120 --> 33:16.860
dann

33:16.860 --> 33:19.000
ist die Vorstellung, dass ich die irgendwo

33:19.000 --> 33:21.080
zentral habe und dann jedes neue Software

33:21.080 --> 33:23.120
Projekt gegenlaufen lassen kann.

33:23.440 --> 33:25.040
Weil ich meine, Fakt ist

33:25.040 --> 33:26.940
einfach, wenn ich mir heute ein

33:26.940 --> 33:28.640
Fahrzeug anschaue, ja, ich meine,

33:30.380 --> 33:30.980
ich sage mal, vor

33:30.980 --> 33:33.080
zehn Jahren hat man gesagt, so Oberklasse

33:33.080 --> 33:34.720
Fahrzeug, 65,

33:35.040 --> 33:36.560
vielleicht 70 Steuergeräte.

33:36.960 --> 33:38.820
Heute sind wir bei gut 100,

33:39.180 --> 33:40.760
vielleicht über 100 Steuergeräten

33:40.760 --> 33:41.800
und

33:41.800 --> 33:44.740
da ist so viel Software drauf.

33:45.240 --> 33:46.000
Das ist einfach,

33:47.000 --> 33:49.320
da muss man was machen, definitiv.

33:49.320 --> 34:07.360
Und wenn ich natürlich sehr viel Software anschauen kann und so eine Datenbank aufbauen kann von Queries, die wird für Automotive Software anders ausschauen wie für irgendwelche Media Player oder für irgendwelche Software im Smart Home Bereich und so weiter und so fort.

34:08.700 --> 34:12.800
Das sehe ich eben auch als Vorteil von diesem Tool, deswegen hatte ich da nochmal nachgefragt.

34:13.140 --> 34:17.580
Das kann ich voll nachvollziehen und es erlaubt halt ein bisschen mehr Customizing auf Ihre Anwendungsfälle.

34:18.100 --> 34:18.400
Genau.

34:18.400 --> 34:29.440
Und da suchen Sie dann auch noch Leute, die jetzt helfen, diese Machine Learning Algorithmen zu trainieren für ihren überlebenden Kontext, dass die Queries entsprechend passen, oder?

34:30.480 --> 34:38.680
Auch, also im Prinzip, ich sage mal, wir sind da noch recht frisch an dem Thema dran, ja, da ist noch nicht viel gelaufen.

34:41.440 --> 34:45.780
Wir werden jetzt ab April hoffentlich ein bisschen verstärkter drauf schauen.

34:45.780 --> 34:48.380
aber klar, wir sind auch

34:48.380 --> 34:50.660
auf der Suche, wie kann man diese

34:50.660 --> 34:52.700
Machine Learning Ansätze nutzen

34:52.700 --> 34:54.280
weil ich sage mal, was ich mir

34:54.280 --> 34:56.720
bisher angeschaut habe in dem Tool waren solche

34:56.720 --> 34:58.720
relativ einfachen Anfragen

34:58.720 --> 35:00.920
dann habe ich ein paar Buffer Overflows

35:00.920 --> 35:02.740
mal ein bisschen probiert zu finden

35:02.740 --> 35:04.500
also es ist halt noch alles

35:04.500 --> 35:05.540
ziemlich frisch

35:05.540 --> 35:08.040
Ja

35:08.040 --> 35:10.540
ich hätte noch eine kleine Frage

35:10.540 --> 35:12.720
zwei eigentlich, haben Sie das Tool

35:12.720 --> 35:14.300
mal über TrueCrypt Code

35:14.300 --> 35:15.540
rüberlaufen lassen?

35:15.780 --> 35:21.660
Mich interessiert ja immer, Sie wissen ja, dieses Schicksal von TrueCrypt ist ja immer noch irgendwie in der Schwebe.

35:21.780 --> 35:24.520
Das wurde damals auf einmal abgekündigt, angeblich unsicher.

35:25.040 --> 35:28.480
Niemand wusste was, die CT oder Heise hat es auch untersucht, haben nichts gefunden.

35:28.880 --> 35:29.900
Haben Sie es sich mal vorgenommen?

35:30.460 --> 35:34.140
Ne, also TrueCrypt habe ich mir mit dem Tool nicht angeschaut.

35:34.300 --> 35:36.380
Aber das wäre ein tolles Projekt, oder?

35:36.760 --> 35:40.340
Das wäre nochmal eine spannende Frage, weil das interessiert viele in der Security Community.

35:40.340 --> 35:44.280
Das wäre eine schöne These, das mal zu zerlegen und schauen.

35:44.280 --> 35:54.100
Und das zweite ist, das Tie.c, der Parse Master, haben Sie sich den Code sicher angeschaut, der da fehlerhaft ist.

35:54.480 --> 35:58.180
Würde man das erkennen bei einer Source Code Inspection?

35:58.340 --> 36:00.220
Also ich gucke mal drauf auf den Code.

36:00.600 --> 36:04.680
Hätten Sie den Fehler entdeckt oder würden Sie sagen, also wahrscheinlich nicht?

36:06.120 --> 36:11.220
Sagen wir es mal so, es kommt drauf an, wer drauf schaut.

36:11.220 --> 36:28.340
Also klar, wenn Sie sich mit Software Security und solchen Stack, also so Buffer-Wolf-Lows auskennen, Sie hätten den Fehler gesehen, aber das Problem ist einfach in so einer großen Organisation wie Bosch,

36:28.340 --> 36:38.300
Ich meine, ich habe jetzt nicht die Zahl von Softwareentwicklern weltweit, aber alleine in Indien haben wir irgendwas zwischen 18.000 und 22.000.

36:39.100 --> 36:43.820
Und über die komplette Organisation sind das vielleicht 74.000 Entwickler.

36:44.260 --> 36:49.200
Ich kann nicht jedem Entwickler verklicken, wie das mit den Buffer-Flows funktioniert.

36:49.200 --> 36:59.960
Und wenn ich so ein Tool hätte, was mir quasi solche, ich sag mal, dummen Fehler schon mal irgendwo rausfischt, dann wäre da schon viel mit gewonnen.

37:00.100 --> 37:04.960
Also das ist einfach klar, das ist nicht die absolute Sicherheit, wird das damit nicht geben.

37:05.360 --> 37:10.680
Keine Frage. Nein, nein, ich wollte es nur wissen, weil ich habe mir kürzlich mal so ein paar iOS-Fehler angeschaut.

37:11.000 --> 37:18.740
Und da muss ich ganz ehrlich sagen, gerade so im XML-Parsing-Bereich, wenn Objekte allokiert werden und dann auch wieder freigegeben werden und alles,

37:18.740 --> 37:21.000
Das ist eigentlich fast undurchschaubar.

37:21.100 --> 37:25.780
Da festzustellen, dass jemand fälschlicherweise an einer Stelle zu früh etwas freigegeben hat,

37:26.020 --> 37:28.480
was dann doch noch verwendet wird und solche Sachen,

37:29.280 --> 37:33.920
da muss man echt in der Code-Inspektion sagen, das ist extrem schwer zu finden.

37:34.180 --> 37:38.020
Da muss ich eigentlich schon fast wissen, dass da was ist, sonst werde ich das nicht mehr finden.

37:38.140 --> 37:39.920
Das ist einfach zu undurchschaubar.

37:40.560 --> 37:45.060
Und klar würden dann Tools, die sowas nachgehen, ganz klar natürlich hilfreich.

37:45.060 --> 37:50.360
weil manuell würde ich eher sagen, also da ist die Grenze ziemlich schnell erreicht, was man finden kann.

37:50.600 --> 37:53.300
Ja, was man auch von Komplexität begreift.

37:53.880 --> 37:57.320
Ja, dann sage ich nochmal vielen Dank.

37:57.660 --> 37:57.940
Gerne.

38:00.280 --> 38:05.980
Und jetzt würde ich sagen, sollen wir einen fliegenden Wechsel machen zu dem Thema DDoS und Mirai

38:05.980 --> 38:09.360
mit unseren beiden Masterstudierenden hier.