Fuzz Off: Wie man Code aufrüttelt, um ihn richtig zu machen – Podcast

  • Ist Fuzzing nur etwas für die Cybersec-Elite oder sollte es für alle Softwareentwickler zugänglich sein? FuzzCon-Teilnehmer sagen, dass sie sich an der Party beteiligen, wenn sie über Erfolge und Misserfolge beim Fuzzing berichten.

    LAS VEGAS – Im Jahr 2014 begannen zwei Teams von Sicherheitsforschern unabhängig voneinander mit Fuzz-Tests von OpenSSL. Innerhalb weniger Tage führte die fortschrittliche Blackbox-Softwaretechnik zu einer ausnutzbaren Schwachstelle in OpenSSL, nämlich der Heartbleed-Schwachstelle.

    Was ist Fuzzing? Genau darum geht es bei der FuzzCon-Veranstaltung. Die Black Hat war letzte Woche nicht die einzige Veranstaltung in der Stadt: Die FuzzCon hat eine Reihe von Software-Sicherheitsexperten und Branchenführern in eine Blackbox gesteckt und ihnen gezeigt, was es mit Fuzzing auf sich hat – einem aufkommenden Trend bei kontinuierlichen Softwaretests, der das White-Hat-Hacking automatisiert.

    Fuzzing ist ein Elitewerkzeug, und so ist es nur logisch, dass Heartbleed – einer von vielen Fehlern, die mit Fuzzing aufgedeckt wurden – von Elitetestern entdeckt und bestätigt wurde: Neel Mehta von Google entdeckte die Sicherheitslücke, während das finnische Unternehmen Codenomicon (jetzt Synopsys) sie bestätigte.

    Fuzzing ist eine Technik zur automatisierten Suche nach Implementierungsfehlern durch Einspeisung fehlerhafter/halbfehlerhafter Daten. Es mag zwar fortschrittlich sein, aber heutzutage gibt es viele kostenlose Open-Source-Tools, die auch von Nicht-Elite-Mitarbeitern genutzt werden können, wenn sie ihre eigenen Sicherheitstestprogramme entwickeln.

    Auf der FuzzCon-Sitzung “Fuzzing Real Talks!” in der vergangenen Woche erörterte eine Gruppe erfahrener Führungskräfte aus dem Bereich der Anwendungs- und Produktsicherheit die Einzelheiten der Einrichtung eines erfolgreichen Sicherheitstestprogramms, einschließlich der Auswahl von Tools, der Rechtfertigung des Nutzens, der Einbindung der Organisation, der Entwicklung einer Strategie und mehr.

    Zwei der Diskussionsteilnehmer, Damilare D. Fagbemi von Resilience Software Security und Anmol Misra von Autodesk, gaben uns im Threatpost-Podcast einen Vorgeschmack auf die Tipps, Tricks und Warnungen, die sie am Donnerstagabend zum Thema Fuzzing geben werden.

    Für Fagbemi und Misra ist dies keine Party nur für geladene Gäste. “Ich denke, wenn wir wirklich erfolgreich sein wollen, müssen wir es an die Entwickler oder zumindest die Qualitätssicherung weitergeben”, sagte Misra. “Ich habe in der Vergangenheit den Erfolg gesehen, wenn die QA-Arbeit [on] Codeabdeckungsstücke, als ob man [all neighbors]. Das geht quer durch das Unternehmen.”

    Er wies auf Beispiele hin: Microsoft hat Fuzzing ermöglicht, wie natürlich auch Google: ein Unternehmen, das “einige erstaunliche Erfolge” hatte, sagte Misra, Heartbleed sei ein Beispiel dafür.

    Podcast anhören, Tool herunterladen

    Um einen Blick auf Misras und Fagbemis Fuzzing-Tipps, -Tricks und -Vorsichtsgeschichten zu werfen, können Sie den Podcast hier herunterladen, die Episode unten anhören oder nach unten scrollen, um eine leicht bearbeitete Abschrift zu lesen.

    Außerdem finden Sie hier einen Link zu dem im Podcast erwähnten Fuzzing-Tool Mayhem, einem Tool zur Automatisierung von White-Hat-Hacking, das bei der Cyber Grand Challenge 2019 der DARPA den Sieg errungen hat.

    [Blocked Image: https://media.threatpost.com/wp-content/uploads/sites/103/2021/07/27093135/threatpost-webinar-300x51.jpg]Machen Sie sich Sorgen, woher der nächste Angriff kommen könnte? Wir halten Ihnen den Rücken frei. Melden Sie sich JETZT für unser kommendes Live-Webinar “How to Think Like a Threat Actor” an, das in Zusammenarbeit mit Uptycs am 17. August um 11 AM EST stattfindet, und finden Sie heraus, wo genau Angreifer Sie ins Visier nehmen und wie Sie dort zuerst ankommen. Schließen Sie sich der Moderatorin Becky Bracken und den Uptycs-Forschern Amit Malik und Ashwin Vamshi am 17. August um 11 Uhr EST für diese LIVE-Diskussion an.

    Leicht bearbeitetes Transkript

    Lisa Vaas: Meine heutigen Gäste sind Damilare D. Fagbemi von Resilience Software Security und Anmol Misra von Autodesk. Sie haben im Podcast vorbeigeschaut [last week] um uns eine Vorschau auf eine Sitzung zu geben, die am Donnerstagabend auf der FuzzCon unter dem Titel Fuzzing Real Talks stattfindet. Bei der FuzzCon, die virtuell und zeitgleich mit der Black Hat in Las Vegas stattfindet, dreht sich alles um autonome Sicherheit, Anwendungssicherheit und die Rolle, die Fuzzing bei der Sicherung von Code spielt.

    Willkommen zum Threatpost-Podcast.

    An der Podiumsdiskussion nehmen vier erfahrene Führungskräfte aus dem Bereich Anwendungs- und Produktsicherheit teil, die über die Besonderheiten eines erfolgreichen Sicherheitstestprogramms sprechen werden. Sie geben Tipps, Tricks und Warnungen zu allen Themen, von der Auswahl der Tools über die Rechtfertigung des Nutzens bis hin zur Einbindung der Organisation und der Entwicklung einer Strategie.

    Aber lassen Sie uns zunächst zu den wirklichen Grundlagen zurückkehren. Könnten Sie kurz beschreiben, was Fuzzing ist, wer es benutzt und warum?

    Damilare D. Fagbemi: Kurz gesagt geht es beim Fuzzing darum, verschiedene Arten von Eingaben an die Schnittstellen eines Systems oder einer Software zu liefern, um die Robustheit zu überprüfen und zu verbessern.

    Der Schnittstellen-Fan macht diese Software. Die Systeme werden also an den Eingangspunkten des Systems beeinflusst. Wir wollen also sehen, wie das System in der Lage ist, auf unerwartete Eingaben zu reagieren. Wie hält es sich, und wie kann man seine Reaktion auf unerwartete Eingaben verbessern? Das ist es also, was Fuzzy ausmacht, und so habe ich es für uns beschrieben.

    Anmol Misra: Ich denke, das ist eine akkurate Beschreibung davon. Das Einzige, was ich noch hinzufügen möchte, ist. Es hängt davon ab, wofür man Fuzzing macht? Das ist der andere Aspekt, richtig? Fuzzing kann also eine ganze Reihe von Dingen tun. Und aus dieser Liste von Dingen, für die man Fuzzing einsetzen kann, was ist der Anwendungsfall, der mehr Sinn macht?

    Das ist eine Sache, die ich hinzufügen möchte, denn in manchen Fällen macht Fuzzing keinen Sinn.

    Lisa Vaas: Und wer benutzt es? Penetration, Tester, Software-Ingenieure, Global 500?

    Anmol Misra: Fuzzing wird von einem breiten Spektrum von Akteuren eingesetzt, aber in erster Linie von Sicherheitsfachleuten, Produktsicherheit.

    Software-Sicherheitsingenieure führen also Tests in den SDL-Entwicklungsphasen und dann Penetrationstests durch. Zumindest einige fortgeschrittene Versionen davon in der Produktionsumgebung. Das sind also die beiden Hauptakteure, die diese Art von Tests durchführen, soweit es die Unternehmen betrifft.

    Viele Unternehmen versuchen, dies zu tun. Wie gut sie es machen oder welche Art von Fuzzing sie in der Lage sind, in großem Maßstab durchzuführen, das ist für mich wirklich eine relevantere Frage, denn mit Fuzzing allein erhält man nicht die Ergebnisse, über die wir sprechen.

    Lisa Vaas: Bitte geben Sie mir eine Vorschau auf die Tipps, Tricks und Warnungen, die Sie an die Teilnehmer weitergeben werden.

    Anmol Misra: Die Dinge, die ich den Leuten, die zum ersten Mal Fuzzing-Programme erstellen, mit auf den Weg geben würde, sind, dass man sich darüber klar werden sollte, warum man Fuzzing betreibt, weil man es zur Codeabdeckung macht. Tun Sie es auch aus anderen Gründen? Das gibt Ihnen ein gutes technisches Verständnis.

    Und natürlich schauen Sie sich technische Modelle und Vertrauensgrenzen an. Aber das sollte Ihnen einen technischen Startpunkt geben. Der andere Punkt ist ein kultureller, oder? Wie fügt sich diese erste Prüfung in das gesamte Portfolio der Sicherheitsprüfungen ein, das wir haben?

    Man geht zum Arzt und bekommt eine Reihe von Tests, und es gibt eine Begründung dafür, dass man zuerst einen Test macht und dann, wenn nötig, den zweiten Test. Das ist richtig. Wenn wir Sicherheitstests durchführen, müssen wir sicherstellen, dass wir wissen, was jeder Test abdeckt.

    Damilare D. Fagbemi: Wenn wir über Finanzierung sprechen, warum fallen wir dann? Zunächst einmal haben Sie die Codeabdeckung erwähnt. Sie wissen schon, wie viel des Codes effektiv erforscht wurde, um zu sehen, wie er sich verhält und wirklich, über Schnittstellen, wie der Code Schnittstellen.

    Wir sprechen also darüber in Bezug auf die Frage, wo wir fuzzeln sollen? Wie bestimmt man, wo man etwas tun sollte? Dinge wie schnelle Tests und was sind die Möglichkeiten. Welche Möglichkeiten bieten sich mit Fuzz-Tests in Bezug auf die Aufarbeitung, welche Art von Problemen haben wir durch die Tests gefunden, die das Team nicht schon mit anderen Testtechniken gefunden hat, wie fließen Fehler in die Modelle der Softwareentwicklung ein, wo man versucht, Software superschnell auf kontinuierlicher Basis zu veröffentlichen?

    Ich habe auch noch eine Frage an Anmol. Vorhin haben Sie erwähnt, dass oft Leute, die Pen-Tester für die Produktsicherheit einsetzen. Sollte es etwas Spezielles für diese Leute sein, oder sollte es etwas sein, das für jeden Softwareentwickler zugänglich ist, sowie eine Technik, mit der man die Robustheit seiner Schnittstellen überprüfen kann?

    Anmol Misra: Ja, das ist großartig. Ich denke, wenn wir wirklich erfolgreich sein wollen, müssen wir es zumindest an die Entwickler oder die Qualitätssicherung abgeben.

    Die Sache, bei der ich in der Vergangenheit Erfolge gesehen habe, ist, wenn die QA das für Codeabdeckungsstücke macht, als ob man ein Nachbar wäre. Das geht quer durch das Unternehmen. Und ich denke, Sie können Beispiele dafür sehen. Microsoft hat es ermöglicht, und ich glaube, Google hat es ermöglicht, und sie hatten einige, einige erstaunliche Erfolge zurück plus diese Programme sind

    Lisa Vaas: Das ist großartig. Ich möchte Sie aber nicht gehen lassen, bevor wir das Gegenteil von Erfolg gehört haben. Warnungsgeschichten, wo machen Praktiker Fehler? Und was ist das Ergebnis?

    Anmol Misra: Ja. Ich denke, es sind die Leute, die Fuzzing zur wichtigsten Sache machen, die sie tun.

    Und ich denke, dass wir an dieser Stelle noch einmal darüber reden müssen, warum man es tut, und wie die Landschaft aussieht und welche Ergebnisse man haben möchte. Der größte Fehler, den ich gesehen habe, ist, dass die Leute … statische Analyse, dynamische Analyse, Pen-Tests, alle Arten von Tests, Fuzzing, machen, ohne zu überlegen, was ist der Return on Investment?

    Und die andere Sache, die ich gesehen habe, ist, wenn man Fuzzing hinzufügt, gibt es andere Dinge, die man von der statischen Analyse wegnehmen kann oder andere Stellen, die man vielleicht nicht braucht? Also wirklich, Kalibrierung von Fuzzing. Ich habe gesehen, dass Programme, die zum ersten Mal getestet werden, an dieser Stelle scheitern, oder dass Leute, die neu im Fuzzing sind, das nicht von Anfang an berücksichtigen.

    Lisa Vaas: Nun, was passiert, wenn Ihr Fuzzing-Programm fehlschlägt? Was sind die Ergebnisse?

    Damilare D. Fagbemi: Manchmal wird dies von den Unternehmen einfach als Anforderung verlangt, fast wie ein Kästchen zum Ankreuzen: “OK, Sie haben einen Fuzz”, und es gibt nicht genug Bewusstsein oder sogar Beteiligung der Entwicklungsteams.

    Die Leute versuchen zu fuzzeln, nur weil ihnen gesagt wird, dass sie es müssen, und haben nicht die richtige Bindung oder Ressourcen oder Anleitung.

    Anmol Misra: Was ich mir ansehen würde, ist: Wie glaubwürdig sind Sie bei Ihren Stakeholdern? Welche Entwickler? Das heißt, man könnte die Frage stellen, ob Sie wirklich wissen, was Sie tun?

    Die statische Analyse an anderen Stellen auch. Es ist also eine Frage der Glaubwürdigkeit, die am Ende aufkommt. Aber es gibt noch einen anderen Aspekt: Wir verpassen eine Menge an [flaws] die nicht entdeckt werden, die dann in der Produktion oder in der Umgebung ausgenutzt werden können. Und das wäre für mich schrecklich.

    Lisa Vaas: Wie rechtfertigen Sie den Wert und wie schaffen Sie es, dass sich das Unternehmen dafür interessiert?

    Was sind die Messgrößen, mit denen Sie um sich werfen, oder die Ergebnisse, auf die Sie verweisen?

    Damilare D. Fagbemi: Ich spreche immer von Dingen wie der Codeabdeckung im Vergleich zu den tatsächlichen Schwachstellen, die wir bei Schnittstellen und Softwaresystemen finden. Ein Beispiel dafür ist, dass in einem bestimmten Zeitraum oder bei verschiedenen Produkten, die getestet werden, Probleme gefunden werden, die sonst nicht gefunden worden wären.

    Also das fällt mir sofort ein.

    Anmol Misra: Die andere Sache, die ich bereits angesprochen habe, ist die Frage, welche Art von Abdeckung Sie neben dem Code für Ihre Schnittstelle suchen, wie Sie erwähnt haben, Ihre Vertrauensgrenzen, wenn Sie diese Art von Programm aufsetzen, das ist der Punkt, an dem Sie anfangen, Metriken zu sammeln. Bevor Sie das einführen, überlegen Sie sich, was Sie den Entwicklern zeigen wollen, zum Beispiel, wie viele, Sie wissen schon, wenn die Fuzzing-Tests zu Ende sind, wie viele Probleme haben Sie gefunden, was ist kritisch und wie stapeln sie es? Vergleichen Sie es mit anderen Arten von Tests, die wir durchgeführt haben. Wenn Fuzzing nur Probleme von mittlerem oder geringem Schweregrad findet und eigentlich gar nichts, oder wenn Fuzzing Probleme findet, die viel mehr Arbeit erfordern, um die Grundursache zu identifizieren.

    Dann denke ich, dass diese Metriken Ihnen nicht die optimale Abdeckung Ihrer Stakeholder bieten werden. Sie müssen sicherstellen, dass das Fuzzing die Probleme, die wir beheben wollen, auf den Punkt bringt und nicht den Entwicklern [just] ‘Hey, hier ist das Ergebnis.’ Das sind die Dinge, auf die ich bei einem erfolgreichen Bericht an die Stakeholder achten würde.

    Lisa Vaas: Gibt es noch etwas, das Sie hinzufügen möchten? Ich weiß, dass es noch viel mehr zu erforschen gibt, einschließlich der Auswahl von Tools und Tricks, aber was sind die wichtigsten Erkenntnisse, die Sie uns mit auf den Weg geben wollen?

    Anmol Misra: Fuzzing ist wahrscheinlich eine Art von Sicherheitstests, die nicht so viel Aufmerksamkeit erhält. Nicht viele Leute verstehen sie so gut, und ich denke, das schränkt unsere Fähigkeit ein, sie zu nutzen, um Sicherheit in der realen Welt zu erreichen. Das ist der eigentliche Grund, warum ich hier bin.

    Damilare D. Fagbemi: Sogar der Name Fuzzing: Was ist Fuzzing? Wir geben einfach eine Menge Inputs – oft auch schlechte Inputs – an eine Schnittstelle eines Softwareunternehmens, um zu sehen, wie sie sich im Test verhält.

    Und viele Bugs … wie z. B. Heartbleed, ich glaube, der OpenSSL-Bug, und andere Bugs, die man auf Mobiltelefonen und Betriebssystemen findet, wurden mit genau dieser Technik gefunden. Und es gibt heute viele kostenlose Tools in unseren Open-Source-Fuzzing-Diensten, die es den Leuten ermöglichen [use] Open-Source-Software zu … fuzz-test by fuzzing [with] Dienste, die immer laufen.

    Ich glaube, auch ForAllSecure hat eine Freemium-Version des Mayhem-Fuzzing-Tools veröffentlicht, damit Startups und kleine und mittlere Unternehmen die Möglichkeit haben, ohne große Investitionen mit Fuzzing zu experimentieren.

    Lisa Vaas: Nun, vielen Dank. Es war mir ein echtes Vergnügen, Sie hier zu haben. Ich lasse Sie jetzt gehen, und ich danke Ihnen, dass Sie sich die Zeit genommen haben, eine Vorschau auf das Panel mit uns zu teilen. Es war mir ein Vergnügen, und ich hoffe, dass Sie beide eine schöne Zeit auf dem Podium haben werden.

    Einige Teile dieses Artikels stammen aus:
    threatpost.com