Für die Novemberausgabe des (IN)SECURE Magazins gab Johannes Greil, Principal Security Consultant und Leiter des SEC Consult Vulnerability Labs einen Einblick in die spannende Welt des Security Researchs. Hier finden Sie die ungekürzten Antworten im Rahmen des Interviews, die als Grundlage für den englischen Artikel „Vulnerability research and responsible disclosure: Advice from an industry veteran“ von Zeljka Zorz, Managing Editor, (IN)SECURE Magazine Ausgabe 59: herangezogen wurden.
Aus dem Inhalt:
Was sind die wichtigsten Anforderungen, um als Security Researcher Erfolg zu haben?
Abgesehen vom notwendigen technisch-praktischen Hintergrund, braucht man auch Spaß an der Arbeit. Wenn es um das Auffinden von nicht ganz offensichtlichen Schwachstellen geht, ist außerdem die entsprechende Zielstrebigkeit und Problemlösekompetenz von Vorteil. Wer dann auch noch geschickt im Umgang mit Herstellern oder dem Verfassen von technischen Texten ist, hat beste Aussichten auf Erfolg.
Was ist beim Bewerbungsgespräch besonders wichtig?
Wir wollen natürlich wissen, ob die Leute das, was sie behaupten, auch wirklich draufhaben. Wir greifen Reverse Engineering Skills genauso ab wie das praktisch-theoretische Wissen in Computerarchitektur und Softwareprogrammierung. Mir ist außerdem wichtig, wie die Bewerber mit Stress-Situationen umgehen, die ihnen dann später das Genick brechen könnten. Und etwas, das du entweder hast, oder nicht, sind natürlich Soft Skills im Umgang mit Menschen. Du musst mit deinen Kollegen aber auch (fallweise unangenehmen) Hersteller-, Kunden,- oder Pressekontakten gut kommunizieren können. Das gehört zum Job einfach dazu. Und, egal ob du im Recht bist oder nicht, als Security Consultant darfst du nie mit dem Finger zeigen, shaming ist ein absolutes No-No bei uns.
Welche Skills sollte man im Laufe der Zeit unbedingt noch erwerben, sofern man sie nicht hat?
Das kommt natürlich ganz darauf an, auf welche Produkte man sich konzentrieren will. In vielen Bereichen sind Reverse Engineering und tiefergehendes Wissen zur Architektur von Systemen sehr hilfreich, während man für Webapps ganz andere Skills braucht. Wer gerne selbst Hand anlegt, also Dinge zerlegt, muss dafür wissen wie er einen Lötkolben richtig hält und was passieren kann, wenn er sich an der Hardware direkt zu schaffen macht. Im Hardware Lab der SEC Consult haben unsere Consultants ein eigenes Diagnoseboard entwickelt, welches bei der Analyse von low-level Informationen hilft, z.B. das Auslesen von Chip-Inhalten.
Gibt es weitere (schwere) Lektionen, die man erst lernen muss?
Hmm… das Lernen hört eigentlich nie auf. Grundsätzlich unterschätzen viele Leute, dass wir ALLE in unserem täglichen Leben von Sicherheitslücken oder Schwachstellen betroffen sind. Und es ist insbesondere für Unternehmen verdammt schwer geworden, jeden Centimeter der eigenen Angriffsfläche zu verteidigen, während ein Angreifer sich auf eine klitzekleine Lücke konzentriert und damit schon ganz viel Böses anrichten kann. Hinzu kommt, dass unter „Security“ oft nur die technische Umsetzung von Sicherheitsmaßnahmen verstanden wird, während die Mitarbeiter (als potenziell schwächstes Element in der Kette) in der Sicherheitsstrategie vergessen werden. Und leider kommt es gar nicht darauf an, ob es sich dabei um einen Berufseinsteiger oder erfahrenen CEO handelt. Wir sind alle nur Menschen, und Menschen machen Fehler.
Dumm wird es insbesondere dann, wenn bestehende Sicherheitsstandards ausgehebelt werden z.B. wenn die Marketingabteilung – vorbei an der IT-Abteilung – eine neue Produktwebsite mit „coolen“ Features oder Gewinnspiele online stellt, die vermeintlich nur ein „kleines“ Risiko darstellen.
Es braucht nur einen motivierten und / oder einfallsreichen (weil gut bezahlten) Hacker da draußen, um an ein System – egal ob online oder offline – zu kommen. Aber wie kannst man wissen, dass man gehackt wurde, wenn nichts Verdächtiges sichtbar ist? Sie werden den Eindringling möglicherweise erst erkennen, wenn es zu spät ist. Hier kommen neue Verteidigungsmechanismen und Täuschungs-Technologien in Spiel. So haben zum Beispiel 2012 meine Kollegen im Zuge eines Incident-Handling Einsatzes eine Lösung entwickelt, die eine ganze Kategorie von Sicherheitslösungen begründet hat – Deception Technologie. Der damalige Arbeitstitel von dem Project ist jetzt übrigens als Cybertrap selbst am Markt erfolgreich unterwegs. Aber das ist eine Geschichte für ein anderes Mal.
Ich erinnere mich noch sehr gut an eine Vorlesung an der FH über Verteidigungsstrategien (Defense in depth). Der Lehrer zeigte uns ein Bild mit einer ultrahochgeschützten Burg und einem Helikopter, der gerade darüber flog. Niemand von unten, in der Burg, dachte an die Möglichkeit eines Luftangriffs und sie waren diesem natürlich hilflos ausgeliefert. Nach wie vor eine sehr passende Metapher für den Job in der Security-Branche.
Wohl eine der härtesten Probe, die man in der IT erfahren kann, hat weniger damit zu tun, was man tut. Sondern wann man es tut: sich gedanklich mit dem Thema Security auseinandersetzen. Wirklich sehr viel Geld könnte gespart werden, wenn man sich bereits am Anfang, also bevor die erste Zeile programmiert wird, schon Gedanken zur Applikationssicherheit macht. Leider sind präventive Maßnahmen wie Application Security Monitoring noch nicht so weit verbreitet, auch wenn sie nur einen Bruchteil von anderen (stand-by) Sicherheitsmaßnahmen im Ernstfall kosten. Sobald ein Angriff entdeckt wurde – sofern er denn jemals entdeckt wird – läuft einem die Zeit davon. Viele Unternehmen beschäftigen sich erst dann mit dem Thema, wenn es zu spät ist, und verstehen dann erst, warum Security ein fundamentaler Bestandteil der Unternehmensphilosophie sein muss.
Welchen Fehler machen viele Einsteiger am Beginn ihrer Karriere in der IT Security?
Man kann die Leute nicht einfach vor einer Schwachstelle warnen, auch wenn es sehr viele Betroffene gibt. Erst wenn es einen Patch oder Workaround gibt, macht es Sinn, die Öffentlichkeit zu informieren. Hacker nutzen die gleichen (oder sogar spezialisierte) Quellen und würden sonst erst recht auf Sicherheitslücken aufmerksam gemacht werden, während es vielleicht noch gar keinen Fix dafür gibt. Manchmal dauert es natürlich etwas, bis der Hersteller ein Update bereitstellt. Insbesondere bei großen Unternehmen oder Unternehmen aus Drittstaaten kann der „responsible disclosure“-Prozess auch sehr zermürbend sein.
Wer auf der hellen Seite des Hackings arbeitet (Stichwort „ethical hacking“) braucht eine ganze Menge an Geduld und wird letztlich oft nur mit einem stillen Update der Firmware und einer Vertraulichkeitsvereinbarung für seinen Einsatz belohnt. Aber so ist das in der Branche, es kräht kein Hahn danach, dass du eigentlich gerade die digitale Welt gerettet hast. Mein Tip: Durchhalten, Weitermachen und irgendwann kommt der richtige Zeitpunkt um sich mit einem Advisory einen Namen in der Branche zu machen.
Wieso entscheidet man sich für einen Job als Security Consultant?
Das ist eine Frage, die wir unseren Bewerbern gerne stellen. Meist beginnen diese dann mit einer Aufrollung ihrer gesamten akademischen Laufbahn und natürlich Jobs, die sie bisher in der Branche hatten. Bei mir fing aber alles viel früher an. Während die anderen Kinder in der Schule auf das erste Moped gespart haben, plünderte ich mein Sparschwein (das meiner Eltern) für meinen ersten 386 SX. Damals waren 25 MHz, 2 MB (!) RAM und eine 105 MB Festplatte noch richtig viel! Das erste Upgrade auf 4MB RAM werde ich nie vergessen, es war alles so viel schneller (lacht).
Meine ersten Hacking-Erfahrungen gehen auf die Zeit zurück, als Sim City gerade aktuell war. Wenn dir das Geld ausging, dann hast du eben den HEX Editor aufgemacht, das Problem dort „gelöst“ und mit unlimitierten Ressourcen weiter gezockt. Wenn ich zurückblicke, war mein Weg in die IT Security wohl vorbestimmt. Im Gymnasium, also vor gut zwei Jahrzehnten, habe ich erstmals mit Backorifice, Netbus, Sub7 Trojanern das Schulnetzwerk auf die Probe gestellt, Stichwort schwache Infrastruktur. Bis heute habe ich mir das total sichere (zwinkert) fünfstellige Passwort unseres Informatiklehrers gemerkt, welches eigentlich alle in der Klasse schon einmal über seine Schulter mitlesen konnten. Danach gab es für mich nichts, das spannender war als die IT Security.
2001 habe ich mich also für den damals ersten Studiengang für „Computer- und Mediensicherheit“ (CMS) an der Fachhochschule Oberösterreich, Campus Hagenberg, eingeschrieben und im Anschluss den Master in „Sichere Informationssysteme“ absolviert. Um mir etwas dazu zu verdienen, habe ich parallel zum Studium schon als Tutor für Fächer wie „Netzwerk- und Kommunikationssicherheit“, „Sichere Mobilsysteme“ oder „Netzwerksicherheit“ ausgeholfen. Ich wurde oft gefragt, ob die Abwärme meiner Server für Storage-Tests (RAID, NAS, …) eigentlich ausreichte, dass wir unsere Studentenwohnung im Winter nicht heizen mussten. Das war leider nicht der Fall, aber die Festplatten und Lüfter haben zumindest für eine alternative Geräuschkulisse zu den üblichen Parties im Studentenwohnheim gesorgt.
ICQ, IRC und Newsgruppen waren damals technologische Mittel, um effizient miteinander zu kommunizieren, aber ersetzten keineswegs die reale soziale Interaktion. Am Campus kümmerte ich mich um den Server für die Newsgruppen (NNTP) der Fachhochschule und war bei fast allen Studierenden bekannt, allerdings nur mit meinem Usernamen, die meisten wussten gar nicht wie ich aussehe. Das war mir nur recht, so konnte ich mich als diagnostizierter „Geek“ meine ganze Zeit mit Hacking, Server, Raid- und Speichersystemen verbringen. Ich hatte damals sogar meine Boot-Sequenz unter Linux so weit adaptiert, dass sie wie eine Kernelpanic aussah. Man musste auf schwarzem Hintergrund ohne jegliche Aufforderung, quasi blind, das richtige Passwort (cryptsetup/LUKS) eingeben, ansonsten würde das System einfach rebooten. Security by obscurity, aber es hat Spaß gemacht das System derart zu modifizieren.
Im Laufe der Zeit absolvierte natürlich auch diverse Praktika und sammelte dabei weitere praktische Erfahrung in den Bereichen Powerline Communications, drahtlose Netzwerke und Backbone Netzwerktests. Kurz nach dem Uni-Abschluss, begann ich mit ein paar anderen Geeks in einem ISP Startup mitzuarbeiten, welches heute noch als wichtiger Bestandteil eines großen Anbieters für Energieversorgung und Telekommunikation in Österreich existiert.
Kaum vorstellbar, aber bis vor ein paar Jahren nutzte ich die Bankomatkarte nie direkt für Bezahlungen in Shops, sondern nur für Bargeldbehebungen am Bankomaten und zahlte in bar. Einkaufen im Internet? Keine Chance. Abgesehen davon, dass ich gar keine Kreditkarte hatte, verbrachte ich meine Zeit eher damit, die Sicherheitsvorkehrungen des jeweiligen Online-Shops zu prüfen. Ich ging lieber “offline” in das jeweilige Geschäft. Auch wenn es alles andere als bequem war, den digitalen Fußabdruck so klein wie möglich zu halten, habe ich dies so lange wie möglich beibehalten, auch nachdem ich bei der SEC Consult als Security Consultant angefangen hatte.
Als ich 2005 (damals noch als Praktikant) bei der SEC Consult an meinem ersten Advisory arbeiten durfte, fing ich dann Feuer für den Research von Schwachstellen aller Art. Es ging um File disclosure und XSS Schwachstellen in einem Produkt von Oracle. Ach, und dann war da noch Horde! Das war richtig lustig, also nicht für die Entwickler natürlich. Denn während ich mit den Entwicklern im IRC zu später Stunde noch dahinter war, eine XSS Schwachstelle zu fixen, kam schon die nächste hervor. Man muss allerdings hinzufügen, dass SEC Consult damals, in 2005, noch aus gerade einmal 10 hochspezialisierten Leuten bestand. Heute sind wir nicht nur um den Faktor 1:20 gewachsen, sondern auf der ganzen Welt vertreten.
Welche Zwischenstationen gab es vor der Leitung des SEC Consult Vulnerability Labs?
- Ab 2006: Security Consultant bei SEC Consult, Wien
- Ab 2011: Teamleiter bei SEC Consult, Wien
- Ab 2012: Leitung des SEC Consult Vulnerability Lab / Research Abteilung
Um die Karriereleiter hochzusteigen, musste ich zunächst mein Wissen rund um Software-Schwachstellen entsprechend ausbauen und Erfahrung in der Leitung von Teams sammeln. Besonders geprägt hat mich in dieser Zeit die Entwicklung eines Responsible Disclosure Prozesses. Sowohl meine Arbeitsweise als auch jene meines Teams wurde dadurch viel effizienter und skalierbarer. Man unterschätzt gern, wie viel sich ändert, wenn man von einer operativen in eine leitende Position wechselt. Plötzlich muss man sich nicht nur um seine eigene Arbeit kümmern, sondern auch jene des ganzen Teams, Mitarbeiter ausbilden, Abstimmungen intern und extern koordinieren und an Dinge denken, die andere noch gar nicht am Radar haben. Leider bleibt am Ende des Tages dann nur noch wenig Zeit, sich selbst dem Research zu widmen oder Hardware selbst zu zerlegen. Du bist eben für die Qualität der Arbeit und Termintreue von allen verantwortlich. Kein Buch und kein Kurs bereitet dich jemals wirklich darauf vor, wie das ist, wenn du plötzlich der „Andere“ im „Toll Ein Anderer Machts“ (T.E.A.M.) sein musst, damit es läuft.
Wie sieht der Prozess aus, was passiert bis ein Advisory tatsächlich veröffentlicht wird?
SEC Consult hat dazu einen eigenen “responsible disclosure”-Prozess entworfen, in dem zwei ISO Standards eine wichtige Rolle spielen.
ISO/IEC 29147:2014 beinhaltet einige grundlegende Richtlinien im verantwortungsvollen Umgang mit potenziellen Schwachstellen, an denen sich Hersteller orientieren können. Es kann manchmal richtig schwer sein, die zuständige Person ausfindig zu machen, wenn es im Unternehmen keinen entsprechenden Prozess gibt. ISO/IEC 30111:2013 beschäftigt sich dann damit, wie gefundene Schwachstellen weiter behandelt werden müssen und stellt Werkzeuge für den Veröffentlichungsprozess bereit. Unser interner Responsible-Disclosure-Prozess gibt den Herstellern außerdem ein sinnvolles Zeitfenster zur Behebung der Probleme und bei Bedarf etwaige Lösungsempfehlungen.
Ein gutes Beispiel war der Fall der Baby-Fons der Marke „Mi-Cam“. Schon im Zuge unseres Researchs im Dezember 2017 hatten wir versucht, den chinesischen Hersteller zu kontaktierten. Als dies nach zwei Monaten immer noch nicht klappte, baten wir das chinesische CNCERT/CC uns für die Koordination zu unterstützen. Leider konnten unsere Emails aber wegen eines Serverfehlers (“550 Mail content denied”) an das CNCERT/CC nicht zugestellt werden, egal ob wir einen Anhang beilegten. Daher wandten wir uns an das CERT/CC. Zwei Wochen später kam vom CERT/CC allerdings die Rückmeldung, dass sie sich an der Koordination und Veröffentlichung der Schwachstelle nicht beteiligen würden. Somit hatten wir alle unsere Möglichkeiten ausgeschöpft und es blieb uns nur noch die Veröffentlichung. Zusätzlich zu unserem technischen Advisory, verfassten unsere Consultants auch einen gut aufgearbeiteten Blogartikel, der den Inhalt auch der breiten Öffentlichkeit verständlich machen sollte, wie extrem unsicher Produkte des sogenannten „Internet of Babies“ (IoB) tatsächlich sind.
Das Ziel unserer Researcharbeit ist immer, die Produktqualität bestehender Produkte zu verbessern und, viel wichtiger noch, ähnliche Fehler in der Zukunft zu minimieren und weitere Verbesserungen in der Sicherheit anzustoßen. Deswegen stellen wir in unseren Adisories auch immer einen kurzen Proof-of-Concept bereit, an dem sich die Whitehat-Community orientieren kann. In manchen, besonders kritischen Anwendungen können wir das natürlich nicht veröffentlichen, aber das entscheiden wir von Fall zu Fall.
Wie werden die Produkte für den Research ausgewählt?
In den meisten Fällen finden Consultants in ihrer täglichen Arbeit z.B. bei Kundenprojekten oder Noteinsätzen der SEC Defence genügend Schwachstellen, sodass wir aufgrund der zeitlichen Ressourcen entscheiden müssen, welche zusätzlichen Produkte explizit für den Research ausgewählt werden können. Sonst obliegt mir natürlich die Letztentscheidung, ob ein Vorschlag für einen neuen Research freigegeben wird oder nicht. Abgesehen davon, darf natürlich jeder SEC Consult Mitarbeiter auch von sich aus Themen für den Research vorschlagen, und das finde ich besonders gut. Zusammen mit einem zeitlichen und budgetären Rahmen, werden diese Projekte dann verglichen und priorisiert. In einer groben Planung zu Beginn des Jahres suchen wir uns außerdem ein paar thematisch passende Advisory-Themen heraus, die entweder gerade aktuell sind oder voraussichtlich aktuell werden (beispielsweise IoT, smarte Dinge etc. …).
Ansonsten kommt es wie es kommt: man kann Schwachstellen zu entdecken nicht planen, und die Veröffentlichung eines Advisories noch weniger (weil es einfach von vielen Faktoren beim Hersteller abhängt). Es ist auch nicht erst einmal passiert, dass wir ganz zufällig oder durch die Medien auf ein heißes Thema gestoßen sind, wie es bei den gehackten Babyfons (FREDI) in Amerika der Fall war. Hier haben wir uns ganz kurzfristig dann eine solche Kamera besorgt und überprüft, ob die aufgestellten Behauptungen aus den Zeitungsberichten auf technischer Ebene tatsächlich nachvollzogen werden können.
Was ist die grösste Herausforderung in der täglichen Arbeit?
Die meiste Zeit geht tatsächlich in der Kommunikation (oder dem Versuch derselben) mit den Herstellern verloren. Die Gründe dafür sind vielfältig: manche hatten das Thema Security scheinbar bisher überhaupt nicht am Radar, andere kein Interesse oder verschleppen den ganzen Prozess sogar mit leeren Versprechungen. Nicht selten versiegt die ohnehin spärliche Kommunikation nach einiger Zeit einfach komplett. Das ist besonders dumm, wenn es keine direkten Ansprechpartner gibt oder wir überhaupt nur über die allgemeinen Kanäle und Postfächer wie „sales@“ oder „info@“ jemanden erreichen – allerdings nicht zwangsläufig die gleiche oder zuständige Person.
Trotzdem versuchen wir natürlich, das Beste daraus zu machen und die digitale Welt mit all ihren Produkten kontinuierlich sicherer zu machen. Deswegen geben wir den Herstellern auch immer ausreichend Zeit, um sich den Schwachstellen anzunehmen und veröffentlichen in den meisten Fällen erst dann, wenn es einen Fix gibt.
Aber, und das möchte ich jetzt noch bewusst hervorheben, es gibt auch die andere Sorte Hersteller: Hersteller, die nicht nur sofort antworten, sondern dankbar für unseren Input sind und binnen kürzester Zeit einen Patch bereitstellen. Es gibt eigentlich kein Advisory, das dem anderen gleicht, und allein durch die unbekannte Komponente der Kommunikation mit dem Hersteller, kann man Advisories auch nicht wirklich auf einen Termin hin planen, egal ob es eine kleine oder große Schwachstelle in einem kleinen oder großen Unternehmen ist. Alles ist möglich. Alles hatten wir bereits.
Welchen Rat sollten sich Neulinge oder Quereinsteiger zu Herzen nehmen, die im Vulnerability Research tätig werden wollen?
Macht eure Hausaufgaben. Tut es nicht für Ruhm und schnelles Geld. Eine Security Bounty zielt immer nur auf eine oberflächliche Lösung ab, beheben aber das zugrundeliegende (ggf. strukturelle) Problem nicht. Dafür müsste man sich ganzheitlich mit Security auseinandersetzen und Dinge auf technologischer Ebene betrachten. Das kostet allerdings Zeit und Geld. Abgesehen davon ist eine Bug Bounty auch für einen Researcher immer ein Risiko. Ja natürlich klingt es nach viel Geld und ist es auch, wenn – und ich betone – wenn man sie gewinnt. Wenn nicht, dann hat man eben ganz viel Zeit in etwas investiert, ohne dafür belohnt zu werden oder einen Bug zu finden oder, schlimmer noch, den Bug nicht als Erster zu finden. Somit ist es eine recht unsichere (haha) Einkommensquelle, im Vergleich zu einer Anstellung in einem Sicherheitsunternehmen.
In meinen Augen gehört es zum Job des Security Consultants, nicht nur Probleme zu finden, sondern auch Lösungen bereit zu stellen. Und das braucht natürlich erst mal viel Erfahrung.
Ein kleiner Ausblick: Wie wird sich der Security Research künftig weiterentwickeln?
Wir leben in einer Zeit des Paradigmenwechsels. Hacker sind besser ausgerüstet als ausgebildete „Geeks“ und haben eine eigene Nische am Arbeitsmarkt begründet. Es wird immer wichtiger, sich permanent fortzubilden, um diesen Wettlauf gegen die dunkle Seite der Technologie zumindest phasenweise gewinnen zu können. Ja das kostet Zeit. Ja das kostet Geld. Aber sonst bleibst du auf der Strecke.
Ich glaube, dass automatisierte Angriffe zunehmen werden, und noch professioneller und teilweise sogar individualisierter ablaufen werden als bisher. Jetzt schon ist die Anzahl an IoT-Produkten nicht mehr wirklich überschaubar. Es führt also kein Weg an automatisierten Tests vorbei, um auch nur eine kleine Chance zu haben, Schwachstellen rechtzeitig zu finden. Wir haben dazu bereits vor einigen Jahren eine Plattform entwickelt, die genau das tut, nämlich automatisiert Firmware auf deren Sicherheit zu testen. Anfangs war es als Unterstützung für unsere eigenen Audits gedacht, mittlerweile kann der „IoT Inspector“ aber auch extern von Unternehmen direkt genutzt werden.
Wenn wir uns also eine Welt vorstellen, in der alles automatisiert abläuft, aber der Mensch an sich ein fehleranfälliges Wesen in sich trägt, wird genau diese „Schwachstelle Mensch“ zum Dreh- und Angelpunkt künftiger Research- und Sicherheitskonzepte werden müssen. Klassisches Pentesting ist aktuell noch sehr gefragt, aber selbst hier werden interaktive Alternativen wie Red Teaming immer populärer. Sicher ist, dass der Vulnerability Research ein spannendes Thema bleiben wird und wer das Wissen, den Tatendrang und das nötige Durchhaltevermögen hat, wird sich in dieser Branche wohl fühlen und braucht sich über einen gut bezahlten Job keine Sorgen mehr zu machen.
