#139 Security Engineering und Hacking-Wettbewerbe mit Frederik Braun von Mozilla

Security Engineering und Hacking-Wettbewerbe “Capture the Flag”

Alles wird digital und für alles gibt es eine App. Bei einer solch rasanten Verbreitung, weckt dies Begehrlichkeiten bei böswilligen Hackern. Was ist also die passende Gegenwehr? Security Engineering! Doch was ist das eigentlich?

Wir sprechen mit Frederik Braun, Security Engineering Manager bei Mozilla und zuständig für den Firefox Browser. Er erklärt uns die Gemeinsamkeiten und Unterschiede von Security und Software-Engineering, wie sich der Bereich Security von einer Web-App und einem Browser unterscheidet, wie Security selbst bei Mozilla aussieht, wie Sicherheitslücken mittels Gamification und Capture The Flag Events gefunden und das suchen geübt werden kann und wie du in das Thema Security Engineering einsteigen kannst.

Bonus: Hackerpraktika an der Universität Bochum

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Sprungmarken

(00:00:00) Intro

(00:00:56) Security Engineering mit Frederik Braun

(00:05:01) Frederiks Kontakt mit Security Engineering

(00:07:51) Werbung/Info

(00:08:51) Frederiks Kontakt mit Security Engineering

(00:18:16) Sub-Bereiche im Security Engineering und Software Entwicklung

(00:28:00) Softwareentwicklung eines Browsers zu anderen Softwarearten

(00:43:34) Was ist Capture the Flag, Bug Bounty und pwn2own?

(01:06:31) Der Einstieg in Security Engineering und Capture the Flag

Hosts

Wolfgang Gassler (https://mastodon.social/@woolf)
Andy Grunwald (https://twitter.com/andygrunwald)

Feedback

EngKiosk Community: https://engineeringkiosk.dev/join-discord
Buy us a coffee: https://engineeringkiosk.dev/kaffee
Email: stehtisch@engineeringkiosk.dev
LinkedIn: https://www.linkedin.com/company/engineering-kiosk/
Mastodon: https://podcasts.social/@engkiosk
Twitter: https://twitter.com/EngKiosk

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Andy Grunwald (00:00:56 - 00:01:33)

Informatik ist ein breites Feld und was mich immer wieder verwundert bzw. Überrascht ist, wenn ich mir meine alten Kollegen aus dem Studium ansehe, für alle, die neu dazu sind, ich habe Wirtschaftsinformatik studiert, was die alles so machen. Also der eine ist irgendwie Projektmanager und dann sind ein paar irgendwie Softwareentwicklerinnen und der dritte, der ist jetzt irgendwie CISO bei, bei irgendwas und so weiter. Also gefühlt machen die alles, wo ich gar nicht wusste, dass man das in dem Bereich Informatik machen konnte, als ich das Studium begonnen habe. Und weil ich habe immer gedacht, wenn ich Informatik studiere oder Wirtschaftsinformatik, dann werde ich so.

Wolfi Gassler (00:01:33 - 00:01:38)

Ich wollte gerade sagen, Wirtschaftsinformatik, der Fehler ist, du kennst die Sachen nicht, weil du Wirtschaftsinformatik studiert hast.

Andy Grunwald (00:01:38 - 00:03:16)

Ja, wie sagte man in einem anderen Podcast, wer Wirtschaftsinformatik studiert, ist nicht der beste bwler und auch nicht der beste Informatiker. Das stimmt, da erzähle ich mich auch zu, aber irgendwie kriege ich doch Sachen in Produktion geschickt. Auf jeden Fall habe ich immer gedacht, okay, cool, wenn man irgendwie Informatik oder irgendwas mit Informatik studiert, wo landet man? Natürlich in der Softwareentwicklung. Und später habe ich gelernt, aber auch Softwareentwicklung ist nicht gleich Softwareentwicklung, denn es gibt den Bereich der Webentwicklung und dann gibt es die Leute, die programmieren die Software auf Waschmaschinen. Und wir haben sogar schon mal mit jemandem gesprochen, der hat ein Entertainment System auf einem Kreuzfahrtschiff programmiert. Und dann gibt es Zeit Reliability Engineers, das sind dann irgendwie Software Engineers, die sich auf Produktionsumgebungen spezialisiert haben und so weiter und so fort. Und ein Teil dieses riesen, ich sag mal, Konglomerats von Informatik ist Security. Denn wenn sogar auf meiner Waschmaschine und auf einem Kreuzfahrtschiff irgendwie Web Apps laufen, dann ist irgendwie alles digital und irgendwie alles angreifbar. Wir haben das Thema Security im Podcast schon so minimal beleuchtet. Und zwar hatten wir einmal in Episode 27 haben wir uns mal über die Dependency Hülle, ich glaube speziell bei Npm und JavaScript unterhalten. Und in Episode 41 haben wir mal ein Deep Dive in sogenannte SQL Injections gemacht. Aber um mal ein bisschen mehr in das Thema Security und Security Engineering einzusteigen und hoffentlich ein bisschen Licht ins Dunkle zu bringen, haben wir einen Gast angefragt und dieser Gast ist dieser Einladung gefolgt. Deswegen begrüße ich. Hallo, Frederik Braun. Hi. Ganz kurz zur Vorstellung, damit die Leute auch wissen, wer denn da eigentlich spricht. Du bist wohnhaft in der deutschen Hauptstadt in Berlin. Du hast ein Engineering Diplom von der schönen Ruhr Universität Bochum im Spezialbereich IT Sicherheit.

Frederik Braun (00:03:16 - 00:03:17)

Genau.

Andy Grunwald (00:03:17 - 00:03:33)

Du warst Assistent an einer Lehrkraft am Lehrstuhl für Network and Data Security und hast da eine tolle Sache gemacht, eine tolle Initiative. Und zwar hast du einen Hands on Kurs für Web Application Security ins Leben gerufen mit dem tollen Namen Hackerpraktikum. Ist so ein bisschen, erinnert mich so an Clubmata, so Hackerbrause.

Frederik Braun (00:03:33 - 00:03:42)

Ja, gab definitiv auch Club Mate dann im Nachgang. Genau, das habe ich mit einem Studentenkollegen, mit einem Freund von mir zusammengeleitet, das Praktikum. Das war sehr gut.

Andy Grunwald (00:03:42 - 00:03:56)

Und inzwischen bist du Security Engineer und Engineering Manager bei Mozilla und du arbeitest seit ein bisschen mehr als 12 Jahren und dort im professionellen Umfeld managst du das Firefox Security Engineering Team.

Frederik Braun (00:03:56 - 00:03:58)

Ist das alles richtig? Ja, ganz genau.

Wolfi Gassler (00:03:58 - 00:04:00)

Bist du eigentlich ursprünglich aus dem Ruhrbot?

Frederik Braun (00:04:00 - 00:04:11)

Ja, ich bin gebürtig in Bottrop und bin dann, weil Bochum halt nah dran ist, habe ich mir nah dran erst mal was gesucht, nach Bochum gependelt, aber irgendwann dann, irgendwann dann nach Bochum rübergezogen.

Wolfi Gassler (00:04:11 - 00:04:21)

Wir haben ja extrem viele Gäste, die aus dem Ruhrpott sind. Ich habe die Vermutung, dass Andi da im Hintergrund irgendwas immer probiert zu manipulieren, dass wir irgendwie Leute aus dem Robot bekommen.

Frederik Braun (00:04:21 - 00:04:22)

Einfach der schönste Teil Deutschlands.

Andy Grunwald (00:04:22 - 00:04:37)

Ja, also das könnte an meiner Manipulationsstrategie liegen. Das könnte auch ganz einfach an dem Fakt liegen, dass Nordrhein Westfalen das bevölkerungsreichste Bundesland von Deutschland ist. Also ich weiß jetzt nicht, was eine höhere Wahrscheinlichkeit hat, aber sehr wahrscheinlich die Anzahl der Menschen hier im Bundesland.

Wolfi Gassler (00:04:37 - 00:04:40)

Ja, Moment, NRW ist nicht Ruhrpott, habe ich gelernt.

Andy Grunwald (00:04:40 - 00:04:49)

Das ist vollkommen korrekt. Aber der Ruhrpott ist halt wirklich extremst lang. Also von Duisburg bis Dortmund, das sind ein paar km.

Frederik Braun (00:04:49 - 00:05:00)

Ich glaube, das ist die größte Metropolregion. Regionen oder so. Wenn man jetzt Superlative auspacken würde, es gäbe ein paar, ist allerdings auch die. Das lassen wir vielleicht lieber für den Podcast. Ist ja nicht alles schön im Ruhrpott.

Andy Grunwald (00:05:00 - 00:05:01)

Aber scheinbar.

Wolfi Gassler (00:05:01 - 00:05:31)

Ich wollte gerade sagen, scheinbar hat es ja auch Gründe gegeben, dass du nicht mehr im Ruhrpott bist. Aber ich will da jetzt keinen Streit entfachen. Aber starten wir mal in das ganze Security Thema rein, wenn wir dann schon so einen Spezialisten haben im Podcast. Danke dafür übrigens. Du hattest, wie Andi erwähnt hat, auf der Universität schon Berührung mit Security. Hattest du davor eigentlich auch schon Berührung? Oder hat dich die Uni irgendwie in das ganze Security Thema reingebracht? Oder hast du schon dein ferngesteuertes Auto mit Sex gehackt oder so?

Frederik Braun (00:05:31 - 00:07:13)

Ich hatte ein ganz cooles ferngesteuertes Auto, aber ich habe das leider nicht gehackt. Nee, aber ich habe tatsächlich immer schon so eine gewisse Neugierigkeit besessen, so ein bisschen mir computer Themen näher anzugucken. Ich bin jetzt nicht irgendwie als mega der Programmierer an die Uni gekommen, aber ich hatte schon so ein Verständnis, wie funktionieren Internetseiten, so ein bisschen Webentwicklung, PHP Lady da gemacht und dann einfach auch schon Berührungspunkte mit Sicherheit gehabt an verschiedenen Stellen. Typische Sache, was so wie ich gehört habe, jedenfalls andere Kinder, der er auch gemacht haben, ist, dass sie dann irgendwann in der Schule für ihre Jahrgangsstufe irgendwie ein PHP Forum aufgesetzt haben und dann irgendwie Gästebuch programmiert, ein bisschen für Spaß, ein bisschen auch, weil, naja, das ist so, was hat man sonst für Stärke mit Leuten reden oder Fußballtore schießen halt leider nicht sozusagen. Und da hatte ich dann tatsächlich einfach ein bisschen Berührung mit tatsächlich auch Websicherheit. Also das klassische Beispiel, wenn du dein eigenes Forum schreibst, ist halt irgendwie XSS Schwachstellen oder SQL Injection und so. Ja, ich hatte das Gefühl, das macht Spaß, da habe ich Bock drauf. Und ich wusste tatsächlich die ersten Semester nicht, ob ich da richtig bin, so, weil ich dachte, boah, das ist schon alles sehr hart und so. Aber ich wusste auf jeden Fall, dass ich nicht einfach nur irgendwie programmieren lernen möchte, sondern dass irgendwie, irgendwie da so ein bisschen mehr sein sollte und bin dann so ein bisschen auch reingestolpert. Die anderen Studenten definitiv. So wie du wusstest nicht, dass das eine Elektrotechnik Fakultät ist? Und dann hatte ich halt echt so fünf Semester der Elektrotechnik, weil man halt auch wirklich Sicherheit in der Informationstechnik gelernt hat. Also ich wäre durchaus dafür ausgebildet worden, irgendwie Schwachstellenanalyse zu machen auf, ich sag mal EC Karten oder so. Das hat mich aber nicht gejuckt. Ich bin da schon mit einem Interesse und ein bisschen Vorwissen, was Web und Netzwerke und Computersicherheit angeht, aufgelaufen und habe das, wie man sieht, auch so ein bisschen durchgezogen.

Wolfi Gassler (00:07:13 - 00:07:15)

Wann war das, wie du angefangen hast, studieren?

Frederik Braun (00:07:15 - 00:07:18)

Das ist lange her. Wintersemester 2006 2007 war das.

Wolfi Gassler (00:07:19 - 00:07:21)

Okay, also da hat es Internet schon gegeben, so?

Frederik Braun (00:07:22 - 00:07:29)

Also ich bitte dich, Wolfgang. Da gab es das Internet schon, aber da war dann gerade so Thema war dann so Web tatsächlich?

Wolfi Gassler (00:07:29 - 00:07:38)

Ja, also ihr wäre 2001 angefangen zu studieren und das war so ein Limit, da ist das Web erst so langsam eigentlich so richtig losgestartet. 2006 war es dann schon.

Frederik Braun (00:07:38 - 00:07:46)

Es gibt ja wahrscheinlich einen Unterschied zwischen gibt es das Internet schon oder und ist es schon an den Universitäten und in den Lehrplänen? Genau, das war es aber schon.

Wolfi Gassler (00:07:46 - 00:07:50)

Okay, da können wir heutzutage vielleicht schon teilweise fragen, ist es angekommen bei den Unis?

Andy Grunwald (00:07:50 - 00:08:26)

Aber gut, ich stelle mir die Frage, du hattest gerade diese tollen PHP Foren und selbstprogrammierte Gästebücher und so weiter erwähnt. Und ich stelle mir die Frage, ich meine, super Viele Leute haben ja damals mit PHP gelernt, weil es ist super einfach zum Einstieg und so weiter. Und heutzutage, jeder hatet ja PHP und die ganzen, ich habe so das Gefühl, die ganzen Neuprogrammiererinnen starten alle mit Node, JS und JavaScript. Also hast du zufällig mal mitbekommen, ob man heute z.B. ein JavaScript basiertes Forum für seine Uni Klasse oder sowas aufsetzt? Oder nutzt man da eher, ich sag mal, jetzt kommt der Boomer aus mir raus, so Facebook Gruppen oder weiß ich nicht, gibt es da TikTok Gruppen oder so?

Frederik Braun (00:09:26 - 00:09:54)

Ich glaube, dass das vieles anders läuft. Ich glaube, heute setzt keiner mehr irgendwie Software aus für seine Gruppe. Ich glaube, da wird dann eher gesagt, komm, wir machen aber jetzt zum Thema Boomer, ich bin ja auch kein Student mehr, aber ich glaube, dann ist das eher irgendwie ein Slack oder eine Discord Gruppe oder vielleicht ist es eine Signal Gruppe oder eine WhatsApp Gruppe oder so. Ich glaube, dass keiner mehr ein Forum aufsetzt. Damals hatte man halt das Internet nicht in der Hosentasche. Ja, ich glaube, das ist der wichtige Unterschied.

Andy Grunwald (00:09:54 - 00:10:27)

Kommen wir mal zu dem Thema Security Engineering. Und wir sind ja ein Software Engineering Podcast. Und wenn ich mir das Wort Security Engineering so aus der Zunge zergehen lasse, dann hat das natürlich die Gemeinsamkeit, dass das Wort Engineering drin ist. Und Security Engineering hat es gerade gesagt, okay, ist gegebenenfalls auch auf Hardware anwendbar. Du sagst gerade ec Karten, aber wir sind ja hier im Softwarebereich und du hast ja auch gesagt, okay, dich hat eher die Software gelockt, eher das Web gelockt. Und deswegen würde ich gerne mal von dir wissen, wenn du jetzt den ersten Paragraf von Wikipedia schreiben würdest, zum Thema Security Engineering im Web, wie würde der erste Paragraf heißen?

Frederik Braun (00:10:27 - 00:11:42)

Schwierig. Ich glaube, ich würde erst mal mit Gemeinsamkeiten anfangen. Ich erlaube mir jetzt dahin zu labern und nichts Wikipedia wörterbuchreifes von mir zu geben. Ich glaube, ganz wichtig ist tatsächlich die Betonung auf Engineering. Es ist, glaube ich, genauso ein ingenieurmäßiges Vorgehen wie Softwareentwicklung oder jedes andere ingenieurmäßige Vorgehen auch. Also man setzt sich klare Ziele, man setzt sich klare Requirements, im Idealfall Ÿousand, und entwickelt halt dahin mit angemessenen Feedback Loops. Also man guckt, was läuft, was läuft nicht, was funktioniert, was funktioniert nicht, verschiedene Arten von testen und dann, ja, darauf zuarbeiten mit eben diesem ingenieurmäßigen, ich gucke mal, was habe ich gemacht, was funktioniert, was funktioniert nicht? Wie baue ich darauf auf? Wobei halt in Security Engineering glaube ich, noch mal ein ganz, ganz anderer Unterschied ist zum Thema Zuverlässigkeit. Da wird halt auch, glaube ich, noch mal, wie man das vielleicht von QA testing kennt, nochmal einfach eine Schippe draufgesetzt, dass gesagt wird, wir gucken uns das Ganze noch mal viel offensiver an. Also es gibt viel mehr Adversarial Testing, dass man halt auch tatsächlich sagt, nicht nur was könnte hier schief gehen im Sinne von hoch, dann stürzt der Server ab, sondern was könnte hier schiefgehen, wenn jemand wirklich mit Vorsatz versucht, da so richtig gegenzutreten? Und wie verhindert man das? Also dass man einfach noch mal die Anforderungen im Security Bereich sozusagen klarer und bewusster abklopft.

Wolfi Gassler (00:11:42 - 00:11:59)

Jetzt hast du gesagt, du setzt dir Ziele oder ihr setzt euch Ziele oder Security Engineering setzt sich Ziele. Was wären es jetzt für Ziele? Du hast jetzt Tests hauptsächlich erwähnt. Sprechen wir jetzt wirklich immer nur von Tests oder ist es normales Programmieren auch? Also was, was will man erreichen eigentlich?

Frederik Braun (00:11:59 - 00:13:15)

Es gibt natürlich ganz konkrete Schutzziele. Danke. Genau. Und zwar die typischen sind eigentlich immer Confidentiality, Integrity, Availability. Das ist so, das steht auch in jedem Software Engineering Textbook, also Vertraulichkeit, Integrität der Daten und Verfügbarkeit. Und Vertraulichkeit wird dann üblicherweise mit Verschlüsselung oder ähnlichem oder Authentifizierung, Autorisierung geregelt, integriert eher mit Autorisierung, dass man halt weiß, wer kann wie wo was schreiben, lesen etc. Und Accessibility, also tatsächlich Zugriff ist dann, da geht es dann um so DOS Angriffe, wenn jemand irgendwie einen Server abschmieren lassen kann, wie wichtig ist mir das? Und das sind wie gesagt, das sind Schutzziele und die muss man dann abklopfen für die für die spezifischen Security engineering sagt man auch Asset, also für die die schützenswerte Güter, also ob es jetzt mein ganz konkreter Server ist, der im Serverschrank steht oder meine Web Anwendung oder spezifisch auf einzelne Backend Services oder APIs, mit denen man sprechen kann, kann man für alle diese Dinge halt Schutzziele definieren und dann absprechen. Das ist jetzt super akademisch high level security Engineering Textbook. Das ist jetzt nicht unbedingt das Format, das wir machen, wenn wir irgendwas entwickeln, dass wir tatsächlich so in dem Sinne konkret diese Matrix ablaufen. Aber super high level ist es genauso.

Wolfi Gassler (00:13:15 - 00:14:03)

Was mir ja immer bei den Sachen so schwer vorkommt. Jetzt wenn ich ein Feature implementiere, ganz klassisch bei einer Software, ich will da ein Formular haben, ich will da einen Button haben, dann ist es klar definiert. Bei diesen Sachen, die du jetzt erwähnt hast, Integrität oder oder Sicherheit ganz allgemein. Das sind ja so sehr schwammige Begriffe, wo ich vielleicht nicht auch klassisch eben so programmiere, jetzt dieses Formular, das ist dieses Feature und ich habe das am Ende, sondern ich muss ja auf irgendwas hinarbeiten, das ich womöglich gar nicht kenne, weil ich kenne ja vielleicht meine Angriffsvektoren gar nicht. Klar gibt es natürlich bugs und so, dann ist es easier, aber du arbeitest ja auf irgendwas hin, was du gar nicht kennst. Also wie entscheidest du denn das? Oder gibt es, gibt es irgendwie Metriken, die man, die man da überhaupt einsetzt, also um dem Ziel dann näher zu kommen?

Frederik Braun (00:14:03 - 00:15:16)

Idealerweise am Anfang, wenn man was baut, ist ein sogenanntes Threat Model, also dass man sich überlegt, welche Angriffsszenarien könnte es geben? Natürlich ist es, wenn man irgendwo einen Knopf hinzufügt, ein kleines iteratives Ding, wo man bereits ein Projekt hat und idealerweise ein Threat Model. Aber das passiert natürlich auch nur in eher reiferen Entwicklungsprojekten, sage ich mal, oder reiferen Organisationen, die eine gewisse Größe haben, wo Security vielleicht ein separates Team ist oder ein ganz, ganz konkreter Prozess, der dann die Entwicklung begleitet. Und in so einem Threat Model guckt man sich halt ganz klar an, wo kommen Daten an, wo fließen sie hin, wo liegen sie? Wo werden sie von potenziellen Angreifern oder Benutzern, das ist dann quasi austauschbar irgendwie angegeben und dann versucht man denen so ein bisschen durch ein im weitesten Sinn Architekturdiagramm zu folgen und zu gucken, wo wo hat man indirekt oder direkt halt Zugriff drauf als Angreifer. Und ein typisches Beispiel halt ich gebe irgendwie in einem Formularfeld, jetzt um in der Nähe von deinem Formular zu bleiben, vielleicht nicht ein Button, sondern ein Inputfeld, da gebe ich halt was an, dann geht es an die API, dann geht es in die Datenbank, dann bleibt es in der Datenbank, dann geht der nächste Benutzer auf die Internetseite, dann geht es von der Datenbank über die API wieder in die Webseite für einen anderen Benutzer, wo sie angezeigt wird. Und an all diesen Stellen würde man dann quasi, das hört sich gerade so.

Andy Grunwald (00:15:16 - 00:15:24)

Ein bisschen an, als wenn ich ein Security Team habe, die mir ein Threat Model erstellen, dass die dann auch so mehr oder weniger meine Technical Writer für die Dokumentation sind.

Frederik Braun (00:15:24 - 00:16:09)

Ja, das wäre schön, da sage ich jetzt was sehr generisches, aber ich finde, wenn man guter, erfahrener Ingenieur sein möchte mit viel Impact, dann sollte man so oder so, glaube ich, üben, Sachen gut und ausführlich aufzuschreiben, damit es andere später nachvollziehen können. Und so ein Threat Model, da muss ich dich dann leider noch mal enttäuschen, entsteht leider nicht, weil man dem Security Team sagt mach mal, sondern das ist ein langes Meeting, man setzt sich zusammen an den Tisch und entwickelt gemeinsam. Das kriegt man leider nicht geschenkt, aber das erarbeitet man gemeinsam. Dann haben halt beide am Schluss ein gutes Verständnis von der Software. Und ja, dieses Threat Model ist nachher ein Artefakt, was extrem nützlich ist für jede iterative Entwicklung. Und ja, das ist es wert aufzuheben. Und natürlich kann man anhand dessen neue Leute ins Team bringen. Bisschen so wie eine Dokumentation. Stimmt schon.

Andy Grunwald (00:16:09 - 00:16:44)

Aber das bedeutet natürlich dann auch, dass der Security Engineering Prozess eigentlich genau wie die Softwareentwicklung dauerhaft mitläuft, oder? Weil ich meine, nehmen wir mal die klassische Web Applikation. Die Web Applikation schreibt irgendwas in die Datenbank und heutzutage hat ja jede Firma hinten dran irgendein Data Warehouse und die analysieren irgendwelche Daten wegen Real Time Entscheidungen und so weiter. Und dann kommt da eine neue Pipeline rein, weil der Data Scientist neue Daten braucht und so weiter und so fort. Also ich meine generell schraubt man ja immer so an einem an einem Formular eins Auto, was sich dann halt konstant weiterentwickelt. Der Motor wird besser und da kommt dann neuer Reifen dran und dann fahren die mit vier, fünf Reifen und so.

Frederik Braun (00:16:44 - 00:16:45)

Weiter und so fort.

Andy Grunwald (00:16:45 - 00:16:59)

Also eigentlich ist ja das Red Model läuft halt immer dann auch nebenher bzw. Sollte doch im Optimalfall dann auch ein ja ein Teil des interdisziplinären Teams sein, oder macht man das einmal und dann iteriert man da irgendwie jedes Quartal einmal drüber.

Frederik Braun (00:16:59 - 00:17:55)

Das geht so und so. Ich glaube, das hängt einfach total ab vom von dem Engineering Modell, das man gewählt hat. Also wenn man jetzt vielleicht kleines Team oder kleines Projekt, das sind eh nur irgendwie ein, zwei Leute involviert, dann sieht es nachher doch wieder wie Wasserfall aus. Ich habe hier mal was fertig gestrickt, morgen muss es live gehen, wer kann drüber gucken? Ist ein bisschen der worst case. Aber das das kennt ja leider jeder und das ist, wenn man irgendwie von außen getrieben ist, von irgendwelchen politischen Ereignissen oder Marketing oder sonst was und sagt oh, hier gibt es eine Gelegenheit, da muss man halt schnell sein. Und dann ist es natürlich nicht gegenseitiges Feedback. Jeder Schritt wird irgendwie begleitet und so weiter. Aber natürlich gibt es auch ganz reife Anwendungen, wo man ein klares Threat Model hat und dann macht man das auch und dann sagt man ah, hier haben wir an folgenden Stellen eh eigentlich schon sichergestellt, dass alle Daten, die ich sag mal über folgende API reinkommen, doppelt und dreifach auf Typ und Länge und Wert und hast du nicht gesehen, getestet werden. Wir machen uns nächste mal wieder. Tschüss, schönen Tag noch. So, da ist alles möglich.

Andy Grunwald (00:17:55 - 00:18:14)

Jetzt sprechen wir natürlich ein bisschen über das Threat Model und ich habe mir gerade die Frage gestellt, okay, wenn ich irgendwie über das Thema Security nachdenke, dann denke ich natürlich immer an die News, die dann irgendwie auf heise läuft, ja, oder letztens in der Bild Mitarbeiter von Microsoft rettet das Internet oder was war.

Wolfi Gassler (00:18:14 - 00:18:16)

Das mit dieser Bild an dich?

Andy Grunwald (00:18:16 - 00:18:54)

Nein, ich habe nur gehört, dass diese xz Backdoor dann irgendwie in der Bild sogar war oder Software Engineerette, das Internet oder ähnliches. So und da denkt man natürlich immer nur an die ganz bösen Hacker und an die Angriffe und an die Exploits und an die CVE und Sicherheitslücken und so weiter und so fort. Aber jetzt sagst du natürlich mit dem thread Model ist das schon eher so eine Arbeit, die würde ich, ich sag mal im Bereich Architektur vielleicht auch ansiedeln. Und meine Frage ist eigentlich, muss jemand im Security Engineering eigentlich mal ein Softwareentwickler oder eine Softwareentwicklerin gewesen sein? Also muss man programmieren können oder gibt es im Bereich Security Engineering, genauso wie ich im Intro von der Informatik erzählt.

Frederik Braun (00:18:54 - 00:20:17)

Habe, Subbereiche, vielleicht nicht Subbereiche, aber in der Tat kann man das unterschiedlich angehen und es hängt glaube ich auch ein bisschen damit zusammen, was genau man testet oder wie leicht das zu testen ist oder vielleicht auch ein bisschen wie Teamkultur oder Firmenkultur sind. Natürlich gibt es ein offensives Testing oder offensives Security Engineering und ein defensives und Ÿousand. Meiner Erfahrung nach ist es immer einfacher, wenn man bei der Entwicklung, bei der Konzeptionierung mit im Raum ist und gemeinsam sich gemeinsam Ziele setzt und die gemeinsam vereinbart. Manchmal ist es aber auch so, dass man vielleicht irgendwie ein Produkt kriegt oder ein Library oder irgendwas, was man dann vielleicht nur irgendwie white label weiter weiterentwickelt oder so. Und da ist natürlich die Möglichkeit einzuwirken bei Konzeptionen einfach eingeschränkt. Zweitausendein jetzt und dann muss man natürlich irgendwie auch Offensive testen. Da muss man sagen, was ist eigentlich meine Plattform, wo ich drauf baue? Wie sieht mein Gerüst aus, dass ich jetzt irgendwie noch verkleiden muss? Und das kann man natürlich besser durch irgendwelche analytischen Tätigkeiten machen, als durch dann mit mit fortentwickeln ausschließlich. Und das kann man natürlich auch machen. Oder ein ganz typisches Beispiel ist, meine Anwendung spricht mit mehreren APIs und nur eine davon liegt wirklich bei uns im Entwicklungsteam und eine liegt in, keine Ahnung, Tochterfirma oder sonst was. Dann macht man halt irgendwie im weitesten Sinne auch offensive test, Ÿousand und das ist dann ein schönes Wort für ich versuche das anzugreifen und schreibe auf.

Andy Grunwald (00:20:17 - 00:20:24)

Was mir aufgefallen ist, dieses offensive testing, ist das auch als Pen testing bekannt, dass ich dann irgendwann.

Frederik Braun (00:20:24 - 00:21:19)

Genau, z.B. man nettes z.B. auch Penetration Testing. Das hängt ein bisschen damit zusammen, was genau man testet, wie man testet. Und da sind die Begrifflichkeiten glaube ich nicht so super klar. Aber ich glaube im Gegensatz zu defensive Offensive macht halt die die Bezeichnung für mich so gerade Sinn. Aber genau Penetration testing heißt ja meistens eigentlich auch oder oft zumindest, dass es irgendwie eine Auftragsarbeit ist, dass man sagt, ich habe jetzt was fertig gemacht. Ich habe im Idealfall mir vorher Gedanken um Security gemacht. Ich habe mir im Vorfeld Gedanken gemacht, wie das irgendwie komplett aussehen soll. Und dann sage ich halt auch noch und das kann genauso im Nachgang passieren oder während der Entwicklung, dass ich sage und dann hole ich mir noch Expertise von außen. Ich weiß, ich benutze eine neue Technologie, das ist in house ist es noch allen total neu. Wir haben definitiv das Beste gegeben und gründlich drüber geguckt, aber wir brauchen einfach noch mal Experten von außerhalb. Und das ist dann meistens dieses Penetration testing, dass man dann sagt Hey, hier ist irgendwie eine Firma, die macht jeden Tag nichts anderes, als diese neue Technologie zu untersuchen. Die will ich haben.

Andy Grunwald (00:21:20 - 00:21:48)

Ich hatte mal Kontakt zu einer Firma, Agentur, die sowas dann gemacht hat in unserem Auftrag und den haben wir glaube ich, einfach nur einen Endpoint gegeben von einem System und einfach mal mehr nicht. Und ich glaube, das war irgendwas zum Speichern von Kreditkartendaten, also PCI, DSS Certification und so weiter. Da musste man glaube ich, so ein Report einreichen und das war schon, das war schon sehr spannend. Und dann, ich glaube, wir haben eine separate Umgebung gegeben und denen nicht diese Produktionsumgebung gegeben. Also ich hätte naiverweise einfach den Produktionsendpoint.

Frederik Braun (00:21:48 - 00:21:52)

Gegeben, aber aber wenn da schon die Kreditkarten drin sind, dann und dann kam.

Andy Grunwald (00:21:52 - 00:22:22)

Da einen ellenlangen PDF raus. Also die haben uns dann auf gut deutsch zugeschissen mit Papier. Ich habe keine Ahnung, ob das dann wirklich umgesetzt wurde, ob das dann einfach in der Schublade gelandet ist. Aber kommt dir auch sowas mal bekannt vor, dass da echt viel Papier erzeugt wird von diesem Report? Ist toll, dass da was gefunden wurde. Aber meine Frage ist halt immer, wie praktisch sind denn die gefundenen Lücken da? Oder wie theoretisch? Also gibt es ja auch Bereiche im Security Level Ÿousand oder im Security Engineering, so eine Balance. Also wie praktisch ist das hier wirklich anwendbar?

Frederik Braun (00:22:22 - 00:23:39)

Ich glaube, das ist gerade wenn es um Penetration testing geht, was irgendwie von externen kommt. Ich glaube, da ist sehr, sehr viel gewonnen mit einem extrem guten Onboarding, extrem guten Absprechen, was verlangt man, was möchte man, was weiß man, was man braucht. So, und wenn man, wenn man vielleicht nicht weiß, was man braucht, dann klickt man sozusagen generisch Pentesting an, legt das in den Warenkorb, klickt auf Abschicken und dann kriegt man vielleicht auch generisch PDF zurück für generisch URL rein raus, so nach dem Motto. Das kann aber wirklich ganz unterschiedlich sein. Ich glaube, da muss man auch, was ich sehr empfehlen kann, wenn man regelmäßig penetration testing macht, dass man tatsächlich nicht immer nur eine ein und dieselbe Firma hat, dass man sich tatsächlich, wenn man es z.B. im Rahmen von irgendwelchen Testing einmal im Jahr macht, das machen glaube ich viele Unternehmen, dass man sich immer mal wieder jemand neues anguckt und dann tatsächlich auch wirklich intern vergleicht und auch da irgendwie iteriert, verbessert, überlegt, was was habe ich davon, was will ich davon haben? Und das weiß man natürlich nach dem ersten Penthouse Report weiß man besser, was man haben will, als als vor dem ersten. Und was natürlich auch, glaube ich, total wichtig ist, um jetzt vielleicht den Ruf des Penetration Testers noch mal zu retten, es gibt einen total großen Unterschied zwischen Whitebox und Black Box testing. Das heißt halt, ich darf reingucken oder ich darf nicht reingucken. Und wenn ich nur eine URL habe, dann weiß ich vielleicht auch nicht direkt, was die Schutzziele sind oder was die Anforderungen sind oder die Wünsche von dem entsprechenden Team.

Andy Grunwald (00:23:39 - 00:23:41)

Was heißt reingucken in diesem Kontext?

Frederik Braun (00:23:41 - 00:24:24)

Achso, ja, sehr guter Punkt. Quelltext ist ein ganz gutes Beispiel. Wenn ich eine URL habe, dann habe ich meistens nicht den Quelltext, weil das Spannende ist ja im Backend. Also 99 % der Fälle ist das Spannende im Backend. Und wenn man sich den Quelltext anguckt, dann sieht man ja auch als Tester, wo wurden irgendwie schon Schutzmaßnahmen vorgenommen. Da kann man gezielt gucken, sind die robust? Wenn die nicht robust sind, dann weiß ich, das sollte robust sein, weil sonst hätte man da nicht schon die ersten zwei, drei Schritte gemacht. Genau. Oder wenn man halt irgendwas sieht, wo überhaupt nichts vorgenommen wurde, dann kann man halt generisch irgendwie in die Tasche greifen und sagen, hier sind all die typischen Requirements, die wir abgeben für zweitausendeinundzwanzig, keine Ahnung, Vertraulichkeit und dann könnt ihr überlegen, ob ihr euch da was picken wollt oder ob das für euch total irrelevant ist. Aber im Idealfall, wie gesagt, viele häufige Gespräche besser als URL rein, PDF raus.

Andy Grunwald (00:24:24 - 00:25:23)

Jetzt hattest du schon Source Code bzw. Quelltext angesprochen und mit Whitebox testing in Verbindung gebracht, dass Leute dann anscheinend auch Source Code lesen. Und ich glaube, das ist so das klassische Bild, was Leute vom Security engineer haben. Die lesen ganz viel Source Code, sehen irgendeine Code Stelle und oh, das ist eine Sicherheitslücke und dann zweitausendein probieren die da so lange aus. Und der Wolfgang hatte ja auch schon erwähnt, dass man eigentlich etwas sucht, wo man noch gar nicht wirklich weiß, was man sucht. Man sucht irgendwie eine Sicherheitslücke. Und da frage ich mich natürlich und das ist jetzt eine stereotypenhafte Frage, Entschuldigung an alle Leute, die das betrifft, welches besondere Attribut sollte denn ein Security engineer beziehungsweise jemanden, der Source Code liegt und nach aktiven Sicherheitslücken sucht und auch testet, mitbringen? Weil also für mich kommt irgendwie Ausdauer in den Sinn. Also ich hasse es wie die Pest, wenn ich drei Tage an einem Bug rumarbeite und ich kriege den nicht reproduziert oder nicht gefixt oder ähnliches und später ist es eh immer ein Zeichen. Und irgendwie ist ja Security engineering, Source Code lesen ja eigentlich genau das, was ich jetzt gerade so als hassend beschrieben habe, oder?

Frederik Braun (00:25:23 - 00:26:54)

Ganz ehrlich, ich glaube, da hast du schon den Nagel auf dem Kopf getroffen, so, man braucht glaube ich echt ein großes Maß an Ausdauer, gerade so am Anfang, sage ich mal, wenn man noch nicht so ein Gespür entwickelt hat. Ich glaube, Erfahrung spielt eine große Rolle und die kann man sich ja in verschiedenen Art und Weisen irgendwie aneignen, ohne jetzt, keine Ahnung, drei Jahre im Job zu sein. Eine andere Sache, die ich sehr, sehr schätze, ist tatsächlich Neugierigkeit und den Willen immer noch was zu lernen. Was verbirgt sich hinter dieser Zeile Quelltext wirklich? Welche Abstraktionen gibt es hier, die von Framework, Programmiersprache, Browser, JavaScript, APIs, was auch immer. Was wird mir da tatsächlich geboten oder gezeigt und was verbirgt sich darunter? Also tatsächlich, was ich so im Rahmen der letzten Jahre gelernt habe, ist, dass sich Security ganz, ganz oft anspielt an irgendwelchen vermeintlichen Grenzen von Abstraktionsebenen oder oder Grenzen von irgendwelchen, ich sag mal Netzwerkkomponenten oder so, wo der eine denkt, der andere macht aber was macht der eigentlich wirklich genau und was erwartet er eigentlich wirklich genau? Und dann noch mal dreimal nachfragen, aber wirklich, wirklich und noch mal einmal drunter und dann purzelt teilweise tatsächlich schon was raus. Also diese Neugierigkeit definitiv, gewiss auch diese Ausdauer und und ich glaube auch so, um Ausdauer vielleicht noch mal anders darzustellen, so ein gewisser Nervenkitzel Sportsgeist und den entwickelt man tatsächlich, indem man es ein bisschen rausprobiert. Weil ich meine, ihr kennt das ja wahrscheinlich auch, wenn man irgendwie was entwickelt hat und dann lädt man das zum ersten Mal und es läuft einfach und es sieht gut aus. Das ist ja ein unfassbar schönes Gefühl.

Andy Grunwald (00:26:54 - 00:26:57)

Aber auch sehr verwirrend. Also warum funktioniert das jetzt hier?

Frederik Braun (00:26:58 - 00:27:49)

Ja, das kann auch sein. Aber wenn man irgendwie ein klares Ziel hat oder vielleicht sogar den Tipp Ÿousand Test Suite mit irgendwie 100 Tests oder so und man schreibt eine Komponente gegen den Test Suite und auf einmal läuft es durch und überall ist ein grüner Haken hinter. Das ist ja ein mega gutes Gefühl. Ja, und genau so ein Rausch ist es ja auch für den Security Engineer, wenn man irgendwo was eintippt und dann macht es puff und dann und dann liegt der Server da oder dann gibt es irgendwie irgendwie ein pop up für mein XSS Testbeispiel oder typisches Beispiel, wenn man irgendwie Desktop Software gehackt hat, dass man irgendwie auf Ÿousand, dass ein Exploit als Proof of Concept immer eine andere Anwendung öffnet. Und die andere Anwendung, die man demonstrationsweise öffnet, ist der Taschenrechner. Also im browser Szenario ganz konkret. Ich gehe auf eine böse Webseite und auf einmal geht der Taschenrechner. Dann weißt du wow, irgendjemand hat es gerade geschafft, Befehle auf dem PC auszuführen. Und das ist ein unfassbar gutes Gefühl. Das ist ein kleiner Rausch tatsächlich.

Andy Grunwald (00:27:49 - 00:27:53)

Als Disclaimer, wenn wir von Rausch sprechen, da sind glaube ich, dann nur Endorphine im Spiel.

Frederik Braun (00:27:53 - 00:27:55)

Das sind nur Endorphine, aber man sieht.

Wolfi Gassler (00:27:55 - 00:27:57)

Bei Freddy schon das Leuchten in den.

Andy Grunwald (00:27:57 - 00:27:58)

Augen, wenn er darüber spricht.

Frederik Braun (00:27:59 - 00:28:00)

Ja, das ist es.

Andy Grunwald (00:28:00 - 00:28:34)

Zum Thema Sportsgeist kommen wir gleich noch im Laufe des Podcasts, aber vorher möchte ich noch einen Themenbereich mal ansprechen. Und zwar ist das das Thema Browser. Und zwar würde ich gerne mal von dir wissen, wie unterscheidet sich denn eigentlich die Softwareentwicklung eines Browsers zu anderen Softwarearten bzw. Aber auch das Security Engineering eines Browsers zum Vergleich mit Software, die auf meiner Waschmaschine z.B. läuft oder auf einem Kreuzfahrtschiff. Ich sag mal Sachen, die halt jetzt nicht so zugänglich sind oder die Software.

Wolfi Gassler (00:28:34 - 00:28:36)

Die dann im Browser läuft.

Andy Grunwald (00:28:36 - 00:28:50)

Ja, eine klassische Webseite, eine PHP Webseite oder React oder JavaScript oder so. Was würdest du sagen, wie unterscheidet sich die Entwicklung eines Browsers, die Softwareentwicklung und der Security Aspekt eines Webbrowsers?

Frederik Braun (00:28:50 - 00:29:27)

Ich glaube, da gibt es ein paar spannende Alleinstellungsmerkmale. Ich glaube, wenn man es zynisch formulieren möchte. Das hat mal hat man Arbeitskollegen gesagt. Ich fand das sehr erschreckend, wie er das formuliert hat, aber ich bringe das mal vor und dann kommt gleich sozusagen das Happy End. Und zwar der hat gesagt, wir bauen im Endeffekt eine Art virtuelle Maschine, indem wir es dem Benutzer erlauben, Anwendungen aus dem Web runterzuladen, live auszuführen, ohne dass das Betriebssystem in irgendeiner Weise beeinträchtigt wird. Weil das ist es ja. Ich gehe auf beliebige Webseiten, die schicken mir Code, mein Computer soll den ausführen, aber irgendwie soll das nur im Browser bleiben und nicht rausgehen.

Andy Grunwald (00:29:27 - 00:29:28)

Schon scary, oder?

Frederik Braun (00:29:28 - 00:31:17)

Und das zynische war halt und wenn man sich die letzten 20 Jahre anguckt, so richtig gut haben wir es nicht geschafft, weil natürlich gibt es immer mal Sicherheitslücken in Browsern. So, aber wie gesagt, das ist die zynische Variante, die ich glaube ganz positive Variante ist. Bis jetzt haben wir sie ja auch immer wieder gefunden und behoben gekriegt. Es ist ja nicht so, als hätten wir Sicherheitslücken dieser 20 Jahren klaffen, sondern es sind iterativer Prozess und wir haben massiv viele neue Features in den Browser gebaut und in den allermeisten Fällen passiert es den Leuten ja eben nicht, dass sie auf eine Webseite gehen und dann geht der Taschenrechner. Das ist glaube ich so super high level finde ich das eine super Beschreibung. Es ist im Endeffekt eine krasse virtuelle Maschine. Wir laden Anwendungen aus dem Computer und wir wollen, dass sich das sicher anfühlt und sicher verhält. Und das ist eine mega große Herausforderung. Das Schöne aber wie ich finde, ist, dass es gleichzeitig einen extrem reifes Produkt ist, was Security engineering angeht. Also oft sind wir auch involviert oder helfen aus bei neueren Produkten, die wir die Mozilla irgendwie herstellt und helfen dann mit, weil da vielleicht Prozesse noch ein bisschen frischer sind, vielleicht auch Produkte noch ein bisschen mehr Greenfield und so weiter. Aber was ich am Browser wirklich zumindest bei uns schön finde ist, dass obwohl es extrem nischig ist und es jetzt nicht irgendwie im Vergleich zu vielleicht tausenden oder oder Zehntausenden von Security Engineers, die es in der Welt gibt, gibt es natürlich nicht so super viele Leute, die sagen browser Security, klar, kein Problem, kann ich. Das lässt sich aber sehr, sehr schön aufteilen und es gibt erstaunlich viel, was man schon gut machen kann und erstaunlich viel, was wie ich glaube, wir schon richtig gemacht haben, was in typischen anderen Desktop Anwendungen noch nicht so eine große Rolle spielt. Also wir machen auch viel Cutting Edge Security, was ich sehr, sehr cool finde. Von Sandboxing principle of least privilege bis hin zu tatsächlich neue Arten von Sandboxing die andere Software noch gar nicht eingesetzt hat.

Wolfi Gassler (00:31:17 - 00:31:36)

Irgendwie, wenn du auch virtuelle Maschine und so weiter sagst, erinnert das ja auch schwer an ein Betriebssystem mittlerweile, oder es ist ja der Browser ist ja fast schon Betriebssystem. Blickt ihr da irgendwie auf die Betriebssystem Welt, wie die vorgehen, wenn es um Security geht? Könnt ihr euch da irgendwie was abschauen oder von Herangehensweisen kopieren?

Frederik Braun (00:31:36 - 00:32:35)

Tatsächlich ja, typisches Beispiel und damit bewege ich mich jetzt auf sehr, sehr dünnem eins, weil ich da auch nicht so super der Experte bin. Aber ein typisches Beispiel ist ja, wenn du dein Computer startest, dann bist du ja erst im sogenannten Real Mode und dann kannst du tatsächlich den kompletten Arbeitsspeicher beliebig beschreiben. Dann bootet das System, dann bootest du in Betriebssystem. Das macht dann für dich nochmal das wirkliche Speichermanagement mit deinem RAM und bietet ja virtuellen Speicher für die jeweiligen Prozesse, die auf dem Betriebssystem ausgeführt werden. Und was ja passiert ist, wenn ich zwei Programme auf dem Computer starte, dann können die eigentlich nicht in den Arbeitsspeicherbereich des anderen Programmes irgendwie reinkommen und reinlesen, obwohl das ja eigentlich alles der gleiche Ramriegel ist sozusagen. Das ist dieses sogenannte Virtual Memory und eben solche solche Möglichkeiten von Zugriffstrennung. Und so weiter machen wir im weitesten Sinne auch. Ich sage im weitesten Sinne, weil ich wirklich nicht gut verstanden habe, wie Betriebssystem Sicherheit funktioniert. Aber da gibt es halt auch verschiedene Schutzklassen oder verschiedene Adressräume.

Wolfi Gassler (00:32:35 - 00:33:07)

Ist es eigentlich vielleicht noch eine Frage gleich dran gehängt. Ist es eigentlich komplexer geworden in letzter Zeit, wenn ihr auch im Browser einfach mehr APIs durchreicht aufs Betriebssystem, einfach da wesentlich mehr Features in die Richtung baut, dass es dann auf der Security Seite auch viel, viel komplexer geworden ist, weil früher hat man einfach nur, also ganz früher nur HTML, da gab es noch fast kein JavaScript und that's it. Und mittlerweile kannst du im Browser so viel machen. Wir nehmen gerade auf und die Videos werden lokal gespeichert und und und. Also da hat sich viel getan.

Frederik Braun (00:33:07 - 00:34:56)

Ja, da hat sich extrem viel getan. Also als ich noch angefangen habe bei Mozilla, da habe ich erst nur Websicherheit gemacht. Da war ich gar nicht im Browserteam. Da war der Browser ein Prozess, den ich gesteuert habe. Und wenn ich dann gestartet habe und wenn ich dann im Taskmanager nachgeguckt habe, stand da ein Prozess und der hieß Firefox Exe und da war alles drin. Und so ein bisschen, bisschen Revolution war da Chrome, der auf einmal unfassbar schnell war und halt schon Sandboxing und ein Multi Process Modell hatte, wo es tatsächlich so war, es gibt einen Prozess, der den ganzen Operating System Betriebssystemteil übernimmt, spricht mit der Hardware, spricht mit dem Betriebssystem und dann gibt es einen separaten Prozess, der tatsächlich Web Rendering macht und dann hast du ein snappy user interface, wo Dinge schnell reagieren und so weiter. Und gleichzeitig hast du auch eine Privilege Separation, also eine Aufteilung von Berechtigungen. Also dieser Prozess, der Web Rendering macht, der muss halt nicht mit dem Betriebssystem sprechen, der muss halt nicht beliebig Dateien schreiben können, sondern der kann halt sagen, folgende Datei möchte ich ablegen. Ist es ein Cookie? Es ist irgendwie was für den Cache. Und dann gibt es da so eine Kontrollinstanz als den tatsächlichen Prozess, der dann mit dem Betriebssystem und das ist, glaube ich, ein super spannendes Teil, was viele andere Software nicht unbedingt tut. Und was dann Firefox hat dann irgendwann gleichgezogen. Wir haben auch diese Multi Process Architektur und was in ein paar Jahren dazugekommen ist, ist ein sogenanntes Site Isolation. Mittlerweile starten wir tatsächlich für jede Site, also Site im klassischen Sinne, die leichte, grobe Übermenge von einem Origin im Web. Jedes Site kriegt einen eigenen Prozess. Also im Endeffekt kannst du dir das vorstellen von vorher zwei Prozesse, jetzt jeder browser Tab einen eigenen Prozess. Und wenn die iframes cross site sind, dann kriegen die auch nochmal einen eigenen Prozess, dass wirklich, wirklich die Betriebssystemisolierung zwischen Prozessen benutzen, um auch eine Isolierung zwischen Webseiten herzustellen.

Wolfi Gassler (00:34:56 - 00:35:01)

Jetzt hast du schon lese Privilege am Anfang erwähnt. Entspricht das jetzt genau diesem, diesem Approach dann?

Frederik Braun (00:35:02 - 00:39:31)

Das entspricht genau diesem Approach, genau. Und was man sich damit erkauft ist, da werde ich jetzt nicht in die Tiefe gehen, aber es gab ja zweitausendein sehr schwerwiegende Prozessor Sicherheitslücken vor ein paar Jahren, das wahrscheinlich auch hier noch nicht vorbeigegangen ist, weil das war, ich weiß nicht, ob es auch in der Bild war, aber es war wirklich im Radio. Ich habe morgens das Radio angebracht und dann wurde darüber gesprochen. Ich dachte so, wow, und meine Frau ist es wirklich so ernst? Und ich so, ich glaube, es ist wirklich so ernst. Und das waren die Angriffe, das sagt einigen vielleicht noch was, Specter und Meltdown, wo halt einfach in Anführungszeichen rausgefunden wurde, dass wenn ich Code, den ich nicht vollständig kontrolliere, im gleichen CPU Prozess, im gleichen Betriebssystem CPS ausführe wie meinen eigenen Code, dass man den nicht robust voneinander isolieren kann, weil das bis auf die CPU runter in Anführungszeichen kaputt ist oder schwierig zu isolieren ist, wegen Pipelining, wegen Branch Prediction haben, dass die vorher halt gucken, was wird vermutlich als nächstes ausgeführt. Und das ist nicht frei von side Effects, aber da gehe ich jetzt gar nicht so sehr tief ins Detail. Jedenfalls haben wir gemerkt okay, wir führen Code, der nicht komplett unseren ständig ist, aus und zwar halt JavaScript Code. So, der kommt von überall her und wir können aber das nicht eins zu eins kontrollieren. Deswegen müssen wir tatsächlich jederzeit, also example, dot com, gegenexample.net oder was auch immer voneinander isolieren und die kriegen alle einen eigenen Prozess. Das sind glaube ich schon so ein paar Sachen, wo Softwareentwicklung im Browser noch mal echt eine Spur härter und spur interessanter wird als in anderen Software Projekten. Eine andere Sache ist ich glaube fast alles, was wir oder sehr, sehr viel von dem, was wir als Software bereitstellen, ist im weitesten Sinne irgendwie eine API oder Ÿousand oder eine Schnittstelle im DOM, JavaScript, whatever. Das heißt, fast alles, was wir bereitstellen, ist auch tatsächlich sehr, sehr konkret nicht einem möglicherweise Angreifer ausgeliefert, sondern ständig, permanent auf jeden Fall. Also die Annahme ist eigentlich immer, da hat jemand Zugriff, während man bei Software sagen kann okay oder oder bei typischer, typischer Software oder Enterprise Software oder bei irgendwelchen Servern, die im Rechenzentrum stehen, die intern eingenutzt werden, dann kann man dann sagen mache ich eine Firewall drum, kommen die Leute drauf, die bei uns arbeiten oder physical access nur die Leute, die hier im Büro sitzen etc. Etc. Bei uns ist eigentlich die Annahme nee, alles kann in irgendeiner Form irgendwie angegriffen werden und das macht es noch mal anspruchsvoller. Was aber auch extrem cooles Research ermöglicht und das reiße ich lieber auch nur an und vielleicht werfen wir einen Blogpost in die Show Notes, weil da wird es dann auch relativ kompliziert, was wir für bestimmte Software machen, wo wir wissen, die müssen wir einsetzen, weil die im Web gebraucht wird. Typisches Beispiel ist ein XML Parser oder eine Bibliothek, die Ogg OK bis Media abspielt. Da gibt es im Endeffekt nur eins, zwei Bibliotheken, die man benutzen kann, man es abzuspielen. Die kann man nicht nicht bereitstellen. Wenn man halt einen funktionierenden Browser haben möchte, dann muss man ganz viel Funktionalität bereitstellen. Ganz egal, ob man das für aus Security Sicht für eine gute Idee hält. Man macht unfassbar viel mit beliebigen Dateien und beliebigen Formaten. Man muss alles unterstützen. So was wir gemacht haben bei z.B. diesen zwei Bibliotheken, die wir extern als Komponenten reinladen, wo wir aber das Gefühl haben, dass es an Sicherheitsstellen so ein bisschen bedenklich wir nehmen den C Code, compilen den in WebAssembly und dadurch, dass wir den nach WebAssembly compilen, haben wir andere Garantien als ein C Code den hat. Nämlich was WebAssembly macht, ist, es hat seinen eigenen kleinen Speicherbereich und es hat keine wirklichen Schnittstellen nach draußen, sondern es ist wirklich nochmal eine Virtual Machine an sich. Wir lassen das im Endeffekt eine Virtual Machine in der Virtual Machine laufen. Durch dieses WebAssembly machen wir den ganzen Ogg oder XML Parsen Kram intern und schieben das dann wieder raus in unseren tatsächlichen Browser C K Code und haben dann Speichergarantien, die mehr oder weniger unabhängig davon sind, welches Stück Software wir ausführen. Webassembly ist eine neue Webtechnologie, die tatsächlich allen bereit steht und mega kompliziert, low level assembly klingt, aber im Endeffekt ist es eine Möglichkeit, Code im Browser auszuführen, der nicht JavaScript ist. Das heißt, WebAssembly erlaubt es dir, Code als Modul auszuführen, typischerweise in einem Worker, also asynchron, der nicht aus JavaScript kommt. Webassembly ist gar nicht so sehr eine Programmiersprache, die jemand programmiert, sondern wirklich ein Kompilierungstarget. Also wenn ich was geschrieben habe in C Sharp, Rust, C, Python sogar, dann kann ich das nach WebAssembly kompilieren, habe ein WebAssembly Modul und kann das von einer Webseite aus instanziieren. Dann funktioniert das ganz ähnlich wie ein Worker, dass ich so eine eigene Umgebung, eigenes Environment habe und kann dann Daten austauschen über APIs wie z.B. postmessage.

Wolfi Gassler (00:39:31 - 00:39:36)

Und du hast aber Sicherheitsgarantien. Also das Ding kann dann nicht zugreifen auf deine Files auf ein Betriebssystem.

Frederik Braun (00:39:36 - 00:41:12)

Z.B. webAssembly ist wirklich eine Web API, also es kann wirklich so oder so nicht auf Files zugreifen, aber es ist ein bisschen nackter als eine Web API. In der Umgebung, in der sich ein WebAssembly Modul befindet, liegt tatsächlich nichts, außer das, was der, der das Modul instanziiert hat, reingegeben hat. Du kannst Funktionen reingeben, du kannst sagen, okay, ich gebe die Funktion alert rein und dann kann das WebAssembly Modul Alert ausführen oder eine Callback Funktion, was ein bisschen realistischer ist, aber sonst nichts. Also nicht mehr und nicht weniger als das, der das Modul instanziiert hat, da reingegeben hat. Und das ist halt eine total spannende Security Garantie, aber auch total schön für Encapsulation, wenn ich halt irgendwie eine spannende Third Party Library habe für extrem komplizierte Funktionalität. Und das Schöne an WebAssembly ist, es ist unglaublich schnell, also es ist ähnlich schnell wie extrem gut JIT Compiler. JavaScript Code kann extrem schnell und heiß laufen. Und wenn ich jetzt z.B. super schnelle Animationen in einem Canvas machen wollen würde, dann könnte ich das gut, könnte ich diesen Animationscode gut in WebAssembly schreiben und würde dann dem Modul quasi Zugriff zu dem Canvas geben, zu Canvas Methoden. Oder eine andere Möglichkeit ist, ich würde einen supergroßen Array machen, der die Pixel darstellt von von meinem Canvas, wird die ins WebAssembly Modul reingeben mit Request Animationframe, so oft wie der Browser sagt, er könnte jetzt was neues rendern und dann wird das ausgerechnet, dann werfe ich das in Canvas, dann habe ich super schnelle Animationen, ohne irgendwie die Seite wirklich zu blockieren. Also man sieht schon extrem cutting edge security, extrem cutting edge Methoden finden im browser Anwendung, weil wir große Schutzanforderungen haben, große Security Anforderungen.

Andy Grunwald (00:41:12 - 00:41:41)

Du hattest gerade beschrieben, ihr nehmt die XML Library, compiliert die in C und packt die in WebAssembly. Und hattest du Sandbox in Sandbox gesagt, bedeutet das eigentlich auch, dass das auch eigentlich so ein natürlicher Schutz vor Supply Chain Attacken in dieser XML Library ist, wie jetzt z.B. bei der xz Backdoor. Also wenn ich jetzt als Hacker mich als Maintainer in die XML Library rein attacken würde und ich weiß, der Firefox nutzt sie, das würde ja auch bedeuten, dass ihr da so einen naturellen Doppelschutz habt, oder?

Frederik Braun (00:41:41 - 00:42:09)

An der Stelle? Ja, ganz genau. Tatsächlich das schlimmste, was ein Angreifer da drin machen könnte, ist tatsächlich ja, dass das XML komisch gepasst wird, also dass da ein anderes Dokument rauskommt, als eigentlich reinkommen sollte, weil halt wie gesagt Input, Input, Output, viel mehr, viel mehr haben wir nicht. Und da haben wir dann entsprechende Checks halt genau an dieser an dieser Grenze, dass Dinge, die wir da rausnehmen, dass die nochmal bestimmten Checks unterlaufen und dann halt erst als XML Dokument wahrgenommen wird oder als Media File dargestellt wird.

Wolfi Gassler (00:42:09 - 00:42:53)

Jetzt müsst ihr als Browserhersteller ja irgendwie zwei Seiten abdecken. Für mich zumindestens stelle ich mir das so vor. Es gibt die eine Seite eher so die Betriebssystem, Zugriff aufs Betriebssystem, der Browser selbst, ob da irgendwelche Schwachstellen sind und dann den gesamten Code, JavaScript, alles, was ihr so ausführt, also was so vom Web reingeladen wird auf eure Seite und XSS und alles, was es so an Schwachstellen gegeben hat oder gibt. Habt ihr da auf eine Seite mehr Fokus oder wie viel Zeit geht am Ende drauf für die eine oder andere Seite oder ist es ist es 50 50 oder oder ist das Web viel, viel mehr Aufwand und da kommt viel mehr rein, als was es jetzt, wenn es auf der Seite ist zum Betriebssystem hin.

Frederik Braun (00:42:53 - 00:43:34)

Ja, ich glaube, das lässt sich schwierig in Zahlen ausdrücken, aber da gibt es definitiv unter Gruppen, unter Teams bestimmte Dinge, die dann noch mal unterschiedlichen Fokus auch haben oder bestimmte Leute, die unterschiedlichen Fokus haben. Aber alles in allem ist uns das beides wichtig und das machen wir auch selber. Also es gibt die Sicherheit für den Benutzer. Also ich benutze den Browser und nichts geht schief. Und dann gibt es natürlich auch Sicherheit von Web Anwendungen, die wir in irgendeiner Form bereitstellen. Also wenn, wenn du deine Web Anwendung absichern möchtest mit irgendwelchen Security APIs, die die in HTML, JavaScript, DOM und so weiter bereitgestellt werden, dann kommen die zu einem gewissen Grad auch aus unserem Team, aber nicht ausschließlich. Und das bieten wir auch an.

Andy Grunwald (00:43:34 - 00:44:24)

Lass uns mal zu dem Thema Sportsgeist kommen. Und zwar haben wir ja gerade schon festgestellt Security Engineers, die neue Sicherheitslücken suchen, brauchen ganz viel Ausdauer oder auch Neugier und allem drum und dran. Ÿousand und dieses Attribut hat vielleicht nicht jeder. Und was auch bei Social Media Companies funktioniert, wie bei TikTok und so weiter, um irgendwie so kleine Endorphinkicks zu triggern und dauerhaft dich auf den Screen gucken zu lassen, gibt es ja beim Security Engineering auch in irgendeiner Art. Und zwar bin ich über bei der Recherche für diesen Podcast auf einen Begriff gestoßen, das nennt sich competitive security bzw capture the flag. In dem ganzen Realm bist du auch involviert und ich würde gerne mal wissen was habe ich da gefunden? Wovon reden wir hier? Was ist Capture the Flag?

Frederik Braun (00:44:24 - 00:49:08)

Ich kann ein bisschen was erzählen. Bei involviert müssen wir aber eine Fußnote dran machen. Ich mache es schon seit einer Zeit nicht mehr, aber wir fangen mal vorne an. Capture the Flag bezeichnet Security Events oder Competitions oder Wettbewerbe, wo Leute versuchen, was für Spaß zu hacken. Aber das sind halt keine in den allermeisten Fällen keine real World Targets, sondern da gibt es jemanden, ein Ausrichter, der setzt z.B. einen Server auf oder der stellt bestimmte Stücke von Software bereit und sagt hier gibt es folgende Aufgaben, versucht es mal zu brechen und dann ist es meistens im Zeitraum von 24 Stunden, 48 Stunden, 8 Stunden, whatever. Genau. Und da gibt es dann Leute, die versuchen sich dann als Gruppe daran, Dinge zu hacken für Spaß oder um was zu lernen. Angefangen hat das so ungefähr zu der Zeit, als ich tatsächlich anfing, zu studieren, da gab es so ein, zwei Wettbewerbe im Jahr Ÿousand, die wurden dann ausgerichtet, z.B. von der Universität in Aachen war das damals, die RWTH, die hatte den sogenannten Cypher CTF, der war extrem gut und University of California in Santa Barbara, die hatte den sogenannten ICTF, damit hat es für mich so persönlich angefangen. Und die Idee ist einfach, wir stellen einen sicheren Rahmen bereit, wo man hacken kann, ohne irgendwie Sorge haben zu müssen, dass es unschaffbar ist, was glaube ich viele Leute am Anfang denken, so wie soll ich denn jetzt, also warum sollte ich denn jetzt irgendwas hacken können, das haben doch irgendwie alle anderen auch schon probiert. Sondern es ist ganz klar, klar, du gehst mit der Prämisse rein, da gibt es was zu finden und es ist ein relativ kleines Stück, das halt sich nicht der Analyse entziehen will, sondern eben genau dafür da ist, dass ich was Neues lerne. Und da gibt es verschiedene Formate, ein typisches Format ist, das nennt man Jeopardy Format, weil wenn man sich anmeldet, dann kriegt man so eine große, so eine große Tafel, die in verschiedene Kategorien eingeteilt ist, z.B. irgendwie Kryptographie, reverse Engineering, Websicherheit, weiß ich nicht und so weiter. Und dann gibt es, das ist sozusagen die horizontale auftanken von den Spalten und nach unten hin gibt es dann Punktestaffel, also eine Herausforderung für 100 Punkte, 200 Punkte, 300 Punkte, 500 Punkte oder so weiter. Und da kann man sich dann sozusagen durchhaken, man klickt dann an und dann ist da irgendwie ein Szenario, irgendwie eine Beschreibung oder bei einer Websecurity Challenge steht das hier ist folgende URL, versuch mal eine XSS Schwachstelle zu finden oder gutes Beispiel ist vielleicht auch eine SQL Injection Sicherheitslücke, hier gibt es eine Webseite mit Formularfeldern, versuch mal die Datenbank auszulesen, da drin befindet sich irgendwie ein Feld, was zu der user id null gehört, das ist der Admin und tippe das später auf unserer Anmeldeseite vom CTF, tippe das da ins Formular und dann kriegst du Punkte. Das heißt, es kann automatisch bewertet werden. Ich versuche hier irgendwie eine Datenbank auszulesen und dann steht da drin irgendwie Flag, Doppelpunkt und dann lange Zufallszahl und nur wenn ich die rausgefunden habe, dann habe ich sozusagen als Teilnehmer den Beweis, dass ich die Datenbank ausgelesen habe und dafür kriege ich dann Punkte. Und das kann man alleine spielen oder als Team. Und ja, genau wie wir das früher gemacht haben an der Roni, da gab es ein paar ältere Semester, die hatten schon irgendwie CTF gespielt und Studienfreund von mir hat gesagt, du glaubst gar nicht, was ich letzten Wochen gemacht habe, das war so krass, das war so spannend und der hörte gar nicht mehr auf zu erzählen. Der war so begeistert, es war so schön. Die haben aber gesagt, die wollen das nächstes Jahr nicht mehr machen, aber ich will da unbedingt noch mal mitspielen. Ich habe all, ich habe all die Puzzle runtergeladen. Wir müssen es angucken. Das ist unfassbar. Dann haben wir tatsächlich, weil es das damals nur zweimal im Jahr gibt, haben wir es tatsächlich ein halbes Jahr lang geübt und alles versucht, versucht, wie es nur geht, auseinanderzunehmen und haben es wirklich, wirklich zu ernst genommen und haben dann beim nächsten Jahr teilgenommen und haben dann gesagt okay, wenn die älteren Semester sagen, sie wollen vielleicht mal vorbeikommen, dann müssen wir halt jetzt das in die Hand nehmen. Dann gründen wir jetzt ein Team und melden uns an. Und da ist das CTF Team der Ronin Bochum Flachs Fingers entstanden. Dann gab es tatsächlich in der kleinen nerdigen Ecke von Security Engineering gab es tatsächlich so ein bisschen Hype. Mittlerweile ist es so, dass man tatsächlich jede Woche CTF, weil immer irgendeiner was ausrichtet. Und das Niveau ist auch derbe gestiegen, muss ich sagen. Also früher war tatsächlich die einfachste Challenge oder die härtere Challenge war tatsächlich irgendwie eine sequel Injection. Ich mache hier irgendwo ein Apostroph rein und lese die Datenbank aus. Mittlerweile gibt es Herausforderungen, wo es dann darum geht, dass jemand den Quelltext nimmt von einem beliebigen Browser und sagt ich habe hier an folgender Stelle eine Sicherheitslücke eingeführt. Könnt ihr sehen, hier ist der Quelltext. Versucht die mal auszunutzen. Und da muss man tatsächlich durch all die Hürden, all die Isolationsmechanismen, all die schwierigen Sicherheitseigenschaften, die so ein realistischer, echter Target wie ein Browser hat, tatsächlich durch muss zwar anhand von Schwachstellen, die dir gezeigt werden, die bereitgestellt werden, aber dann tatsächlich ein Exploit zu schreiben für den Browser, das ist nicht trivial. Das könnte ich auch nicht mehr, muss ich ganz ehrlich sein. Das könnte ich nicht im Rahmen eines Wochenendes für Spaß Ÿousand mit zu viel koffeinhaltigen Erfrischungsgetränken und Kommilitonen neben mir sitzend. Aber das Niveau ist gestiegen und die Leute machen mit und es ist extrem spannend.

Wolfi Gassler (00:49:08 - 00:49:13)

Jeopardy. Ist es, weil du die Antwort schon kennst, oder habe ich das richtig verstanden?

Frederik Braun (00:49:13 - 00:49:28)

Nein, Jeopardy einfach nur, weil es dieses, weil es dieses Feld gibt, also weil das halt aussieht wie so ein, wie so ein Jeopardy Board in einem Spiel. Du hast verschiedene Kategorien und verschiedene Staffelungen mit Punktezahlen, einfach so als es geht tatsächlich gar nicht um dieses Frage Antwort.

Wolfi Gassler (00:49:28 - 00:49:33)

Jeopardy, aber es ist ja vorbereitet. Also die Lücke ist bekannt in diesem Fall.

Frederik Braun (00:49:33 - 00:51:38)

Im weitesten Sinne ist die Lücke bekannt und du gehst natürlich alles an alles heran, was glaube ich auch total viel mit dem mit der Motivation und der Ausdauer tut. Du weißt, es gibt immer was zu finden. Es ist nicht so, wie wenn ich jetzt sagen würde, so heute setze ich mich mal ran und versuche Firefox zu hacken und dann wo fange ich an? Sondern es ist eigentlich relativ klar und das sind sehr eindeutige Fragen. Also in so einem ZDF steht halt nicht hier ist eine Datei oder hier ist eine URL, mach mal. Sondern eher man stelle sich vor, der Admin hat sein Passwort vergessen, hier ist folgende URL und dann weißt du okay, ich muss versuchen in irgendeiner Form das Passwort vom Admin auszulesen. Entweder ist es irgendwie eine Sicherheitslücke, die es mir erlaubt, Dateien zu lesen auf dem Server oder eine Datenbank aufzumachen und dann ist eigentlich schon relativ klar, wo es hingeht. Und das ist immer sehr, sehr spielerisch, immer sehr, sehr schön. Wir haben damals in der oder das macht mein Team, mein ehemaliges Team Flachs Fingers immer noch CTF ausgerichtet im Rahmen der luxemburgischen Sicherheitskonferenz Hacklu und da haben wir uns immer ein Motto genommen und wir hatten einmal ein Wild, ich glaube wir hatten es World nicht statt World Wild Web hatten wir Wild Wild Web glaube ich als Thema und alles waren irgendwie so Cowboy Geschichten und es war total spielerisch, war lustig, es war Pixelgrafik mit irgendwie Kakteen und eine Windhexe rollte durch und so weiter. Und die Szenarien waren ihm immer irgendwie super absurd und man erzählt schöne Geschichten, man macht sich einen Spaß drauf. Aber was ich sagen will, es ist nie so ja, versuch mal zu hacken, sondern man nimmt sich irgendwie an die Hand Hand und will den Leuten auch was beibringen. Also wenn man CTF macht, dann hat man hat man irgendwie meistens selber irgendwie mal eine coole Sicherheitslücke gefunden oder eine neue Technologie ausprobiert. Wie funktioniert eigentlich NoSQL? Probiere ich das mal aus? Und wie sind die Sicherheitsannahmen oder die Eigenschaften im Vergleich zu MySQL? Und dann schreibe ich mir einfach eine Anwendung, versuche die selber zu ach, das ist ja witzig, das ist ja einfacher, als ich gedacht habe, da mache ich eine Challenge draus und dann kann ich es halt den anderen auch beibringen. Also das war immer irgendwie auch unser Gedanke, dass wir gesagt haben, wir machen was, wir machen was Amüsantes, wo die Leute, die mitspielen, irgendwie auch nach Hause gehen und sagen cool, ich habe jetzt mal die Ausrede gehabt oder die Zeit gehabt, mich mit was Neuem auseinanderzusetzen, was man ja sonst vielleicht nicht.

Andy Grunwald (00:51:38 - 00:52:14)

Da war es wieder das Feuer in seinen Augen und in seiner Stimme. Die Hörerinnen und Hörern haben es wahrscheinlich gemerkt. Er wurde schneller, er wurde oder ich sag mal erregter. Also das war wie so ein kleines Kind hat gerade lego zu Weihnachten bekommen. Wunderschöne Story. Danke dir, Freddy. Du hattest gerade gesagt okay, es werden Sicherheitslücken, ich sag mal vorgezeigt bzw. Es wird es wird in irgendeiner Art und Weise bewiesen. Da gibt es was zu finden. Gibt es nämlich auch Events mit der Flip side, dass man sagt okay, pass mal auf, hier hast du einfach nur ein geupdatetes Betriebssystem. Und so weiter und suche einfach mal. Also gibt es das auch noch mal, ich sag mal in drei Schwierigkeitsgrade schwerer, weil das ist es ja dann im Endeffekt.

Frederik Braun (00:52:15 - 00:54:43)

Ja. Ja, was, was viele vielleicht schon mal gehört haben, was es quasi permanent 24 Stunden, sieben Tage die Woche, 365 Tage im Jahr gibt, ist halt Bug Bounty. Da geht es tatsächlich darum, dass Firmen sagen hier ist unsere Software, wir stellen die bereit, z.B. gehostet auf, ich sag mal Addons mosella Org oder sonst wie oder zum runterladen. Hier sind die Annahmen, die wir tun bezüglich zur Sicherheit. Wir glauben, an folgenden stellen ist nichts mehr zu holen. Probiert mal und wenn ihr was gefunden habt, schickt uns ein e Mail, dann gibt es Geld. Das machen viele große Firmen. Das macht Mozilla auch für Firefox, aber auch andere Produkte. Und da wird ganz klar gesagt, da gibt es Geld, weil wir nämlich eigentlich auch ein bisschen die Wette eingehen und sagen so viel, so viel wird ja nicht mehr zu holen sein, weil unser Topf Geld für dieses Programm ist natürlich nicht unendlich, aber es eröffnet natürlich total viele Möglichkeiten. Erstens für Leute, die sagen ich möchte es mal ausprobieren. Ich möchte diesen höheren Schwierigkeitsgrad und natürlich auch für uns zu sagen, wie man immer sagt vier Augen sehen mehr als zwei. Oder wenn man intern was entwickelt hat, dann hat man ja irgendwie so ganz andere Annahmen, vielleicht auch so ein bisschen Scheuklappen, wo man weiß, das haben wir uns schon tausendmal angeguckt, da wird nichts sein. Und dann kommt einer rum und sagt nee, genau, Ÿousand, da, genau da war leider was. Und das ist ja total schön. Oder vielleicht das bessere Stichwort ist so ein bisschen Betriebsblindheit. Manche Sachen sieht man einfach nicht, weil man nicht denkt und was, was ich immer wieder extrem erhellend finde. So ein Angreifer, der spielt nicht nach den Regeln, der hat nicht die Anleitung gelesen, es ist ihm egal, was in der Anleitung steht, der macht es halt trotzdem und der guckt halt nicht und sagt ja, das eine Team sagt, das andere hat es gemacht und umgekehrt. Das glaubt er nicht, weil er hat das noch nicht mal gehört. Der guckt sich das einfach von A bis zausend an und das ist halt ja im Dungeon A Dragon Terminus vielleicht chaotisch. Der macht einfach ganz egal, was ihnen ans Ziel bringt. Und das kann extrem spannend sein, weswegen ich auch total gerne lese, was in unserem Bug Bounty Programm z.b. so ankommt. Das ist immer extrem erhellend und manchmal natürlich auch irgendwie fasst man sich an die Stirn, denkt oh Gott, warum haben wir das nicht gesehen? Aber das ist das ist das Schöne an so einer Feedback. Und noch eine Ebene höher, was noch komplizierter ist. Es gibt einmal oder ich glaube mehrfach im Jahr mittlerweile gibt es eine Veranstaltung, die heißt, die wird von der Trend Micro Zero Day Initiative heißt es glaube ich, ausgerichtet und da ist es im Rahmen von der Security Konferenz wird tatsächlich eine Bühne aufgebaut und da wird gesagt wir haben hier folgende echte Targets, kommt vorbei und zeig auf der Bühne deine Hacker Künste. Wir machen dir einen modernen Browser auf, du tippst da oben was in die Adressleiste ein und wenn das hochgeht, dann kriegst du tatsächlich große, große Preissummen.

Andy Grunwald (00:54:43 - 00:56:12)

Ich habe mal ganz kurz nachgeguckt und zwar wenn man nämlich bei der Recherche zu Capture Flag irgendwie das bei Google angibt, da kommt nämlich poe to own schon direkt als erstes, mehr oder weniger als bekanntestes. Und da habe ich erst mal nachgeguckt okay, was heißt denn und zwar ist das sogenannte Lead Speak, die Gamer werden das sehr wahrscheinlich kennen und zwar musste ich mir das selbst übersetzen lassen, ich alter Boomer. Und zwar heißt das, wenn man das Gerät oder das Device wirklich hackt, dann pont man es und das wird ausgesprochen mit PWM, also auf zwei, also übersetzt. Und da du ja, wenn du das Device gehackt hast bei diesem Event, darfst du das Device dann auch behalten und das heißt dann own und somit du musst das hacken, um das zu besitzen. Und da habe ich dann auch ein bisschen recherchiert und zwar war das letzte Event, ich glaube im März oder April, da gab es unter anderem haben die glaube ich einen Tesla auch hingestellt. Also theoretisch, wer da wirklich begabt ist, kann sich dann da ein Tesla erhacken und zweitausendein dann ja own to own sozusagen. Aber auch Firefox war mal wieder im Spiel. Und zwar glaube ich, warst du da jetzt dann involviert, nicht im Ponen von Firefox, sondern eher in der Mitigation. Kannst du ein bisschen was darüber erzählen? Wie lief das ab? Wer hat euch, also habt ihr in der Keynote dann in den Resultaten davon erfahren oder wie läuft das eigentlich ab? Die Bühne ist aufgebaut, da steht ein Windows Laptop mit einem Firefox und Leute schießen darauf.

Frederik Braun (00:56:12 - 00:56:29)

Genau, also im Rahmen dieses Events wird deutlich mehr Geld ausgezahlt als in unserem Bug Bounty Programm, weil das von den Ausrichtern auch so ein bisschen als Werbeveranstaltung genutzt wird oder auch um zu zeigen, wir haben Zugriff auf die besten Security Researcher in der Welt, kauft unsere Antivirus, Verteidigungs etc. Produkte.

Wolfi Gassler (00:56:29 - 00:56:38)

Also bei Firefox war das dann ein Preisgeld am Ende, weil beim Tesla bekomme ich den Tesla, bei Firefox, wenn die Firefox bekommen ist, ist eher mittlerweile ist.

Frederik Braun (00:56:38 - 00:57:01)

Glaube ich alles Preisgeld. Früher hieß es wirklich so, wenn du es gehackt hast, darfst du mit nach Hause nehmen. Und da war dann wow, ich kann hier einen Laptop mit nach Hause nehmen. War total interessant, aber mittlerweile hat sich da preislich was verschoben. Und wenn man jetzt bei uns in Firefox einen Security Bug findet mit Sandbox Escape, dann ist es jenseits der beIN to own, das ist mehr als ein Laptop. Und bei pawn to own ist es, glaube ich, irgendwie 40 oder so.

Wolfi Gassler (00:57:01 - 00:57:02)

Also immer ein Tesla quasi, wenn man.

Frederik Braun (00:57:02 - 01:00:33)

Es so umrechnet, nur dass man dann entscheiden kann, was man sich dafür kauft. Genau. Und wie das abläuft, ist die Ausrichter, die entscheiden beliebig, was sie für lohnenswerte Ziele halten oder vielleicht auch was deren Kunden für lohnenswerte Ziele halten. Und dann wird man angesprochen, wird gesagt, so, wir werden, wir werden euer Produkt testen lassen, so ein bisschen, ob ihr wollt oder nicht. Aber alles in allem ist es sehr, sehr, sehr, sehr einvernehmlich. Und dann wird halt gesagt, so der Ablauf ist so jemand kommt auf die Bühne oder jemand meldet sich vorher an, gewusst wird, wer wirklich angegriffen wird. Es gibt so eine Voranmeldung, dann kommen die auf die Bühne, probiert es und ja, wenn es, wenn es gehackt wird, das wird mit dem Video aufgenommen. Da sieht man, geht auf böse Webseite, wow, der Taschenrechner geht auf, ist total unspektakulär. Es gibt einen YouTube Stream. Es sieht so ja, und jetzt aber tatsächlich sind alle mega, mega aufgeregt, mega excited, weil es ist eigentlich doch schon ganz schön cool, aber man sieht es halt irgendwie nicht. Jedenfalls, genau, und dann verkauft er sozusagen seinen Bug an die Ausrichter von und die sagen dann, okay, sie aktualisieren ihre Antivirensignaturen und so weiter und so fort. Das ist deren Anreiz und im Nachgang, das ist auch Teil des Deals, kommen wir dann in den sogenannten Disclosure Room, also in den Raum, wo man dann darüber spricht, was ist passiert, warum ist es passiert? Und der Teilnehmer bringt meistens auch einen Bericht mit, eine PDF Datei, irgendwie 10 Seiten, wo ausführlich erklärt wird, was habe ich getan, was ist passiert, was hätte nicht passieren sollen? Und dann kriegen wir auch den Security Bug und zwar quasi eine halbe h später oder so. Und dann können wir den halt beheben. Zweitausendein. Genau, das ist für uns total hilfreich, total interessant, weil es natürlich, ja, weil es natürlich Sicherheitslücken aufdeckt, die wir im Backbountierprogramm nicht gesehen haben. Und im Gegensatz zum Backbone Programm reicht es uns, wenn uns jemand sagt, hier ist vielleicht eine Schwachstelle, aber da hat jemand eine Schwachstelle gefunden und sie definitiv ausgenutzt, was natürlich noch mal ein bisschen spannender ist, das komplett zu sehen. Genau. Dieses Jahr waren wir wieder target und wir sind eigentlich mehr oder weniger jedes Jahr dabei. Und Teilnehmer war ein Deutscher, Manfred Paul, der hat zwei wunderschöne Bugs mitgebracht, die miteinander verbunden hat. Genau, Firefox gehackt. Und wir nehmen das immer zum Anlass, weil wir halt wissen, im Vergleich zu es ist irgendwie Malware oder ein Virus draußen, was Firefox für alle Benutzer jetzt sofort gefährdet ist in point to one. Ja, das Szenario, wir kriegen eigentlich sofort Bescheid, wir wissen sofort, hey, da ist was und wir können das beheben. Das heißt, bei uns geht da nicht irgendwie überall die rote Sirene los und oh je, oh je, jetzt Alarm, Alarm, wir müssen sofort was machen, weil alle unsere Benutzer sind in. Sondern wir wissen, alle unsere Benutzer wären in Gefahr, wenn das jetzt publik werden würde. Das heißt, wir benutzen das so ein bisschen als, ja, ich sag mal Probealarm, als Feueralarm. Wir wissen, wir wollen incident response machen, wenn pwn to own passiert und machen das dann auch. Das heißt, es ist ganz so ernst wie Angreifer draußen im Web, die halt jeden hochnehmen können, aber wir nehmen es genauso ernst und versuchen so schnell wie möglich den Bug zu beheben und haben die entsprechenden Leute parat. Und in diesem Jahr lief es tatsächlich für uns besonders gut und wir haben in, ich glaube, weniger als 24 Stunden, da gibt es einen Blogpost zu, ich weiß nicht die genaue Zahl, da haben wir es geschafft, eine neue Firefox Version rauszubringen. Also wir haben den Report gekriegt, haben uns das angeguckt und das war dann tatsächlich ein Live Video Call zwischen den ganzen Teams und den Security Engineers. Wir haben uns das gemeinsam angeguckt, direkt nach dem Event, nachdem uns das übergeben wurde und haben gesagt, so was können wir machen. Und eine Schwachstelle war in der JavaScript Engine und der Entwickler hat ich weiß genau, was hier passiert ist und hatte ihn weniger als 1 Stunde tatsächlich schon ein Patch hochgeladen für Code Review und dann ging das alles sehr, sehr schnell.

Wolfi Gassler (01:00:33 - 01:00:57)

Das war aber jetzt im Vergleich zu einem Bounty Programm, wo du mehr Zeit hast und im Hintergrund das ja noch nicht public ist, ist man da schon wirklich dann klar auf der Bühne und jeder sieht es, oder? Also wenn das ein kritischer Bug ist, dann hat die ganze Welt sofort den Bug und im Gegensatz sonst hat man ja doch noch irgendwie eine gewisse Zeit, wo man sich darum kümmern kann, ohne dass er public ist. Also die Gefahr hat man natürlich dann schon, oder?

Frederik Braun (01:00:57 - 01:01:40)

Genau, genau, das ist ein Hauptunterschied. Im Bug Bounty Programm geht es ja eben nicht darum, irgendwie einen Exploit zu zeigen und zu zeigen, ich kann das auf folgende Weise ganz genau so hochnehmen und hier habe ich das von A bis Z durchprogrammiert, sondern es reicht, wenn ich sage, ich glaube, hier ist eine Schwachstelle, mit genügend Arbeit könnte ich da ein Exploit für bauen. Aber wir sagen ja, musste gar nicht, wir wollen keine Exploits, wir wollen eigentlich nur die Bugs finden und beheben. Das ist für uns das Wichtigere, die ja zum gewissen Maß auch die Leistung erbracht wird oder auch bezahlt wird, dass man tatsächlich ein komplettes Exploit schreibt, was alle Schutzmechanismen durchbricht und dem Bug Bound Programm reicht ja, wenn man einen Bug hat für Einschussmechanismus und dann beheben wir den. Wir brauchen keinen, der irgendwie fünf verbunden hat oder so.

Wolfi Gassler (01:01:40 - 01:01:48)

Also es müsste, wenn jetzt jemand ausnutzen will, müsste er selber den Exploit schreiben, weil der Exploit ja nicht public ist. Automatisch oder?

Frederik Braun (01:01:48 - 01:01:49)

Genau, ganz genau.

Wolfi Gassler (01:01:49 - 01:01:54)

Also du gewinnst schon, hast schon eine gewisse Zeitspanne noch, aber auf jeden Fall.

Frederik Braun (01:01:54 - 01:02:30)

Im Rahmen von Pwn to own wird ja tatsächlich der Exploit Code oder Sicherheitsstelle nicht public. Was man wirklich nur sieht ist, jemand geht auf die Bühne, steckt einen USB Stick ein oder tippt ein URL in die Adressleiste, drückt dann auf abschicken und dann geht der Taschenrechner aus sozusagen. Also es weiß viel mehr weiß auch niemand und dann wie gesagt eigentlich nur die Ausrichter von und dann direkt als nächstes wir und dann wie gesagt, beheben wir es sofort. Und in dem Fall waren wir, glaube ich, der erste Hersteller, der ein Patch raus hatte. Und am nächsten Tag gab es für alle Leute eine neue Version von Firefox. Und man musste im Endeffekt nichts anderes tun, als wenn Firefox sagt, es gibt ein Update, zu sagen ja, jetzt einmal neu starten, updaten, fertig.

Andy Grunwald (01:02:30 - 01:02:55)

Das Wort public ist ja jetzt schon in diesem Kontext ein bisschen anders. Also ja, public bedeutet, es gibt eine Sicherheitslücke in Firefox versus bei dem Bug Bounty Programm ist ja gar nichts public. Da wird auch nicht gesagt, weil da kriegt ihr ja eine private disclosure sozusagen. Ich sag mal eine E Mail Hey, ich glaube, ich habe was gefunden. Also da weiß es ja wirklich nur der, der White hat Hacker und und ihr und bei Pontoon ja, okay, das wird live gestreamt, da gibt es eine Lücke.

Frederik Braun (01:02:55 - 01:02:58)

Alle wissen, es gibt was oder nicht genau.

Wolfi Gassler (01:02:58 - 01:03:08)

Okay, aber wenn ich das richtig sehe, ist es eigentlich eine große Werbeveranstaltung, damit mehr Leute in dieser Szene oder mehr in dieser Szene machen.

Frederik Braun (01:03:08 - 01:03:42)

Schon, schon ein bisschen. Man muss natürlich auch derjenige unter unter den vielen Leuten, die zu Hause zu Hause sitzen und gerne hatten, muss man auch zu Dingen gehören, die sich gerne auf eine Bühne stellen, aber gibt natürlich auch entsprechend Geld. Also Ÿousand man, wenn man sich gut vorbereitet, dann ist das natürlich auch lukrativ. Aber klar, das ist natürlich auch für die Security Szene eine große PR Geschichte und für uns natürlich auch, wie gesagt, eine lohnenswerte Initiative, weil wir das wie gesagt als als incident response in anführungszeichen Probe sehen, insofern, als dass wir wissen, nicht alle Benutzer da draußen sind jetzt sofort direkt angreifbar, aber eben angreifbar genug, als dass wir das ernst nehmen.

Wolfi Gassler (01:03:42 - 01:04:04)

Wenn ich mir jetzt überlege, da ist jetzt so viel Geld eigentlich mittlerweile drin, auch bei Bug Bounty Programmen ist natürlich viel Geld dahinter. Glaubst du, dass irgendwie Leute dann gar nicht mehr normale bugs einfach reporten, sondern alle nur mehr über die Bug Bounty Programme gehen und irgendwelche Firmen, die kein Bug Bounty mehr haben, bekommen sowieso keine Bug Reports mehr, weil da gibt es kein Geld zu holen.

Frederik Braun (01:04:04 - 01:05:12)

Es gibt, glaube ich, ganz unterschiedliche Motivationen, um Software Security zu machen. Und ich glaube, manche machen es für und die suchen sich dann die Targets aus, wo sie wissen, dass es Geld gibt und testen die. Manchen Leuten geht zum Anerkennung, manchen geht es wirklich um, ich sag mal Sportsgeist Neugierde. Hier ist ein neues Produkt, das macht irgendwas, was bisherige Programme, die es so bisherige Software noch nie getan hat. Das ist so spannend. Ich will genau wissen, wie das funktioniert und ich gucke, gucke so lange auf den Source Code, bis ich es verstanden habe, weil ich es extrem spannend finde. Oder typisches Beispiel es gibt ein neues Job Ÿousand, das macht irgendwie Sachen cooler für Entwickler. Aber was sind die Kehrseiten? So, dann guckt man das sich so lange an, bis man es verstanden hat und denkt, das ist richtig cool. Aber an folgenden Stellen könnte man noch, hätte man noch oder ist es vielleicht sogar problematisch? Und dann dann sagt man halt Bescheid. Und manchmal ist es egal, ob ob es Geld gibt oder Anerkennung oder sonst was. Dann geht es eigentlich nur darum, dass man coole Technologie irgendwie verstanden hat und vielleicht auch vielleicht sich selbst irgendwie erhöhen möchte, sagen möchte ich habe es verstanden und vielleicht so gut oder vielleicht an einigen Stellen doch besser als die Entwickler selber. Schaut mal, was ich gefunden habe. Und das kann ja auch irgendwie cool sein, kann ja auch irgendwie irgendwie Mehrwert sein.

Andy Grunwald (01:05:12 - 01:05:45)

Wer etwas mehr über pone to own bzw. Von diesem Bug, den Frederik gerade beschrieben hat, wissen möchte, in den Show Notes gibt es den entsprechenden Link zu dem Security Advisory, wo die beiden Lücken auch vorgestellt werden mit den Bugreferenzen und so weiter. Da kann man sich auch mal in die Details vertiefen. Und Freddy, du musst wissen, der Wolfgang bezeichnet alles als Werbeveranstaltung, was von einer Firma gemacht wird, was nicht von einer Uni gemacht wird, was nicht zum akademischen Research gehört.

Wolfi Gassler (01:05:45 - 01:05:47)

Unis können auch Werbeveranstaltungen machen.

Andy Grunwald (01:05:48 - 01:05:50)

Im Endeffekt ist das für mich positiv.

Wolfi Gassler (01:05:50 - 01:05:54)

Werbung ist positiv. Wenn mehr Leute dann in der Szene sind, hast du hier was erreicht.

Frederik Braun (01:05:54 - 01:05:56)

Du musst fast Werbung machen.

Andy Grunwald (01:05:56 - 01:06:19)

Man kann nicht immer erwarten, dass alle Leute die Samariter sind, weil manche machen das auch, um irgendwas nach vorne zu bringen. Und in diesem Sinne finde ich, hat Trend Micro zu Recht eine gute Werbeveranstaltung, weil wenn Security Issues in Open Source Software wie z.B. mozilla Firefox aufgedeckt werden und gefixt werden und dann allen, inklusive dir, Wolfgang zur Verfügung gestellt werden, würde ich sagen vielen Dank Trend Micro für diese Werbeveranstaltung, die ich mir auch sehr.

Wolfi Gassler (01:06:19 - 01:06:30)

Gerne wesentlich besser als eSports oder solche Dinge. Also das macht für mich absolut wenig weniger Sinn als im Vergleich jetzt zu irgend so einer Hacking Bühne.

Andy Grunwald (01:06:31 - 01:06:54)

Okay, lass uns aber mal noch ein bisschen eine Wohltat für die ganzen Leute tun, die jetzt sagen, ich möchte auch dieses Feuer in meiner Stimme und mir in den Augen spüren, wie ich das jetzt hier über diesen Podcast von Freddy gehört habe. Freddy, was würdest du sagen, was gibst du mir an die Hand, wenn ich an das Feld Security Engineering und vielleicht sogar im speziellen Capture the Flag Ÿ einsteigen möchte. Welche persönliche Empfehlung hättest du, wo ich starte?

Frederik Braun (01:06:54 - 01:08:28)

Ja, es gibt tatsächlich relativ viele CTFs, die in Anführungszeichen 24 sieben laufen, wo man sich einfach ausprobieren kann, eben genau für den Einstieg. Was mir als allererstes einfällt, ist Overthewire Org, also Org. Da gibt es viele verschiedene Challenges, auf die man einfach durchklicken kann und ein bisschen ausprobieren kann. Die finde ich total großartig und da gibt es wirklich viele verschiedene Arten, sich mit Security Testing, CTF und so weiter auseinanderzusetzen. Ich weiß es leider gerade nicht auswendig, aber es gibt eine Challenge, die ist tatsächlich genau für Websicherheitslücken. Da gibt es im Endeffekt, gibt es im Endeffekt ein paar Links und man man hackt sich sozusagen durch das erste Level und die Lösung des ersten Levels ist sozusagen das Passwort für das zweite Level und dann versucht man das zweite Level zu lösen und so weiter und man sieht quasi selber irgendwie den Fortschritt und zweitausendein oder kann sich selbst irgendwie bewerten, ohne da wirklich groß Veranstaltungen teilzunehmen, sich ein Team zu suchen und so weiter. Relativ niederschwelliges Angebot. Für diejenigen, die wissen wollen, wie man tatsächlich Buffer overflow exploited, gibt es da auch was? Die haben ganz ähnliches witziges Prinzip. Du kriegst im Endeffekt Zugangsdaten für den Server über SSH, wählst dich da ein und da liegt eine Datei rum und dann versucht man die zu exploiten und die Datei hat Zugriff auf höhere Privilegien und wenn du die exploitet hast, erbeutest du damit auch wieder Zugangs fürs nächste Level, willst dich erneut per SSH ein und so weiter. Das ist relativ witzig, das macht relativ viel Spaß und da gibt es auch eine ganz gute Community. Als ich das letzte Mal teilgenommen habe, war es IRC. Ich weiß nicht, ob das noch IRC ist, ehrlich gesagt.

Andy Grunwald (01:08:29 - 01:08:31)

Das ist auch over the Wire oder was ist das?

Frederik Braun (01:08:31 - 01:09:01)

Over the Wire, ja, da gibt es einfach verschiedene Challenges mit verschiedenen Codenames, die heißen teilweise Leviathan oder Vertex oder so. Und ich mir fällt das total schwer, von Name auf Inhalt irgendwie Rückschläge zu ziehen, deswegen weiß ich es nicht mehr auswendig, aber da gibt es viele verschiedene und diese finde ich super viel ÿousand einen Einstieg. Ansonsten, wenn man irgendwie einer Uni zugehörig ist und vielleicht noch studiert, macht es vielleicht auch total viel Sinn und Spaß zu gucken, gibt es irgendwelche Gruppen in der Nähe und schließt sich vielleicht denen an. Die sind eigentlich immer offen für Neulinge, dass man einfach mal reinkommt und schnuppert.

Wolfi Gassler (01:09:01 - 01:09:04)

Gibt es da irgend so ein Verzeichnis oder so?

Frederik Braun (01:09:04 - 01:10:08)

Es gibt CTF Time, eine Webseite, ich glaube Ctftime org, da gibt es tatsächlich in Anführungszeichen so ein Leaderboard, so eine Liga, da werden alle CTFs gelistet, die demnächst stattfinden und alle Teams, die teilgenommen haben und viele Punkte, die abgeräumt haben. Da kann man sich so ein bisschen durchklicken, da sind die deutschen Teams natürlich auch alle vertreten, aber das ist schon eher höherer Schwierigkeitsgrad. Ich glaube, zum Anfang ist es schön, sich was Kleineres zu suchen tatsächlich. Genau. Und je nachdem, wenn man tatsächlich irgendwie gerade auf der Suche nach einem Bachelor oder Masterstudiengang ist, dann sucht man sich, wenn man da wirklich Bock drauf hat, vielleicht einfach echt eine Uni mit einem guten Team. Und je nach Uni, je nach Team gibt es da tatsächlich echt wöchentliche Treffen, wo auch Leuten was beigebracht wird, wo gesagt wird, so alle Erstsemester, die mitmachen wollen, die nächsten Wochen sprechen wir über, ich sag jetzt mal Cross Site Scripting oder SQL Injection. Kommt rum Dienstag abends und wir probieren einfach ein bisschen. Und ich weiß, dass das bei Flux Fingers definitiv nur so das Ding ist. Das heißt, hier kleiner Werbeblock, ich bin immer noch sehr begeistert von sowohl Forschung als auch Lehre an der Ruhr Universität Bochum und dem CTF, dem Flachsfingers, da kann man auf jeden Fall vorbeischauen.

Andy Grunwald (01:10:09 - 01:10:42)

Die ganzen Links findet ihr natürlich wie immer in den Show Notes. Ich habe fleißig mitgekriegt, Ÿ geschrieben. Hast du noch irgendetwas, was du unseren Hörerinnen und Hörern zum Abschluss mitgeben möchtest? Irgendeinen Appell, vielleicht irgendetwas, was du dir wünschen würdest? Natürlich Weltfrieden, das ist uns klar, aber vielleicht irgendwas, wo jeder einzelne vielleicht irgendwie. Also Weltfrieden kann auch jeder einzelne mit agieren, gar keine Frage, aber jetzt irgendwas im Bereich Security Engineering, Capital Capture the Flag, Open Source, Mozilla firefox oder ähnliches?

Frederik Braun (01:10:42 - 01:12:02)

Ja klar. Erstens für alle, die zuhören und schon tiefer in Security Engineering oder Security testing oder Bug Bounty drinstecken, wir haben ein Bug Bounty Programm, nehmt teil, wenn euch was auffällt, lasst es uns wissen. Sehr, sehr gerne. Und alle, die irgendwie Spaß an Open Source haben, Spaß an offenem Internet, interoperablem Internet, alles was Gozilla so wie ich finde, ausmacht, datenschutzfreundliches Internet. Wir sind eine Open Source Firma, wir machen das, bzw. Firma ist eigentlich fast schon falsch, wir sind gemeinnütziger Verein in Amerika. Wir machen das tatsächlich nicht nur aus Spaß, sondern weil wir es echt wichtig und gut finden und dementsprechend sind wir nicht nur, was unsere Security Geschichten angeht, relativ offen, wenn Dinge nicht mehr irgendwie kritisch sind und Leute bedrohen oder so, sondern versuchen sehr oft mit unseren Dingen umzugehen, mit unseren Prozessen, aber natürlich auch mit unserer Software. Und extrem viel von unseren Ÿousand Dingen ist einfach auf GitHub, also GitHub com Mozilla, GitHub com mozilla security, GitHub com mozilla services und so weiter haben wir unheimlich viele Repositories, wo wir tatsächlich jeden, der Spaß hat, einen Fehler findet oder einen Verbesserungsvorschlag hat, einladen mitzumachen. Und an der Stelle stelle ich mich tatsächlich jetzt nach vorne und sage, wer Fragen hat und sagt ich kann folgendes wo braucht ihr sowas? Schreibt mich einfach an, ich beantworte gerne Fragen zweitausendein. Ich mache es wirklich, weil es mir spaß macht.

Andy Grunwald (01:12:02 - 01:13:07)

Falls ihr nicht wisst, wo man den Freddy erreicht, könnt ihr uns natürlich auch gerne schreiben. Wir leiten das gerne entsprechend weiter. Uns erreicht man entweder über E Mail Adressen in den Shownotes oder über unsere Discord Community. Den Link findet ihr auch auf der Webseite in den Shownotes. Ja, was was soll ich sagen? Du hast mir mein Wochenende jetzt versaut, weil ich habe mir gerade ein bisschen durch over the Wire geklickt. Ich werde eine schwierige Zeit haben am Wochenende. Das liest sich wirklich interessant und schön ist, dass da auch so Schwierigkeitslevel von eins von 10 und so weiter sind. Also der Einstieg scheint auch machbar für mich als als Security Noob in der Hinsicht. Vielen lieben Dank, dass du dir die Zeit genommen hast, mit Wolfgang und mir über das Thema zu sprechen. Wir hoffen natürlich, dass der Freddy einigen Leuten von euch auch eine Art Begeisterung ins Gesicht zaubern könnte. Deswegen schaut einfach mal in die Show Notes, wenn ihr euch mit dem Thema Security Engineering und Capture the Flag weiter auseinandersetzen wollt. Wolfgang, hast du jetzt eigentlich Angst vor jeglicher Software? Weil wenn du das gehört hast, wie breit sind zweitausendein Security doch ist und wie viele Lücken dann da sind und das sogar top up to date Browser auf Public Bühnen aufgemacht werden können. Schon erschreckend.

Wolfi Gassler (01:13:07 - 01:13:29)

Naja, als Firefox User fühle mich natürlich jetzt extrem sicher und vielleicht solltet ihr da draußen, inklusive dir Andi, wieder mal mehr Firefox benutzen. Also ich bin ja ein alter Fan von Firefox und hat jetzt nur, habe nur die Bestätigung bekommen, dass ich auf der richtigen Seite bin und dass Freddy sich darum kümmert, dass ich immer sicher und also alles perfekt.

Andy Grunwald (01:13:29 - 01:13:39)

Ich war früher Thunderbird User, hab's dann irgendwie mal aufgegeben und hab die Tage mal wieder Thunderbird installiert und irgendwie hat mich die Software wieder komplett weggeflasht. Also Wahnsinn, der Entwicklungssprung.

Wolfi Gassler (01:13:39 - 01:13:44)

Bin auch großer Thunderbird Fan. Da kann man halt wirklich was machen. Nicht so wie bei diesem Mac Mail Zeug.

Andy Grunwald (01:13:44 - 01:13:56)

Zum Abschluss sage ich noch, wir warten leider immer noch auf das Jahr 2024. Das ist das Jahr des Linux selbstverständlich. Aber nun gut. Freddy, vielen lieben Dank für deine Zeit und ich wünsche dir noch einen schönen Tag.

Wolfi Gassler (01:13:56 - 01:13:56)

Bye bye.

Frederik Braun (01:13:56 - 01:13:58)

Dankeschön. Danke für die Einladung. Tschüss.

Wolfi Gassler (01:13:58 - 01:13:58)

Ciao.