Kostengünstige Identifizierung bisher nicht-erkannter Sicherheitslücken mit Threat Modeling, Static Source Code Analysis und Dynamic Analysis: Fuzzing

Transkript

1 Kostengünstige Identifizierung bisher nicht-erkannter Sicherheitslücken mit Threat Modeling, Static Source Code Analysis und Dynamic Analysis: Fuzzing Prof. Dr. Hartmut Pohl Geschäftsführender Gesellschafter softscheck GmbH Köln www. softscheck.com

2 Ihre Strategie ist falsch! Sicherheit ist in allen Bereichen der Informationstechnik wichtig allerdings werden die vielen Angriffe betrachtet und nicht die vergleichsweise wenigen Sicherheitslücken (Vulnerabilities)! Denn: Eine einzige Vulnerability kann von einer ganzen Reihe von Angriffen ausgenutzt werden! Darüber hinaus ist gegen Angriffe, die bisher nicht-erkannte (!) also unveröffentlichte - Vulnerabilities ausnutzen, kein Kraut gewachsen, weil diese Angriffe gar nicht erkannt werden können. Diese Angriffe können auch nicht gesucht werden wonach sollte man auch suchen? Keiner kennt den Angriffspunkt, die Sicherheitslücke! Diese Angriffe sind also stealth. Ergebnis: Werden die Vulnerabilities identifiziert (und behoben) können Angriffe nicht mehr erfolgreich sein. In diesem White Paper werden die 3 erfolgreichen Verfahren zur Identifizierung bisher nicht-erkannter Vulnerabilities dargestellt: Threat Modeling, Static Source Code Analysis und Dynamic Analysis: Fuzzing. Inhalt 1 Management Summary Keine Software ohne Fehler? Software-Entwicklungszyklus Threat Modeling Static Source Code Analysis Fuzzing Beispielhafte Fuzzing-Bereiche... 6 Webanwendungen... 6 Embedded Systems... 7 App-Fuzzing Spezielle Anwendungen... 7 Entwicklung proprietärer Fuzzer... 7 Proprietäre Attack Strings Ergebnisse Die erfolgreichsten Verfahren zur Identifizierung von Sicherheitslücken... 8 Threat Modeling... 8 Static Source Code Analysis... 8 Fuzzing... 8 Weiterführende Literatur August 2012 Kostengünstige Identifizierung bisher nicht erkannter Sicherheitslücken Seite 1 von 9

3 1 Management Summary Mit dem Einsatz von Tools zum Threat Modeling (Design Phase), Static Analysis (Implementation Phase) und Fuzzing (Verifikation Phase) werden auch bisher nicht veröffentlichte Sicherheitslücken identifiziert. Der Einsatz dieser beiden Verfahren erfordert in frühen Entwicklungsphasen einen weitaus geringeren Aufwand, als wenn die Software schon ausgeliefert ist (Release Phase) und erst dann korrigiert wird - vgl. Abb. 1. Zudem lassen sich diese Verfahren für viele Anwendungsbereiche einsetzen: Anwendungssoftware (Webapplications, ERM, CRM, SCM, ERP, E-Business, CIM etc.) und Netzwerk-Protokolle, Embedded Systems (auch die Hardware) und Industriesteuerungssoftware (auch proprietärer Systeme) sowie Apps und Applets für smart and mobile Devices etc. Der Einsatz herkömmlicher Verfahren zur Behebung von Fehlern und insbesondere nicht veröffentlichten Sicherheitslücken ist dagegen sehr kostenaufwändig - viele Sicherheitslücken werden erst nach der Auslieferung der Software an die Kunden - z.t. auch von Dritten - erkannt. Den exponentiell steigenden Aufwand zur Behebung (Patchen) von Sicherheitslücken zeigt Abb. 2. Tatsächlich steigt der Patchaufwand nach einigen Untersuchung - u.a. des National Institute of Standards and Technology (NIST) - von der Designphase zur Release Phase auf das 100-fache. Aus eigenen Untersuchungen wissen wir, dass der Aufwand zur Identifizierung von Sicherheitslücken mit Threat Modeling und Fuzzing sehr kostengünstig durchgeführt werden kann auch wenn sich die Software schon auf dem Markt befindet. Sicherheitslücken werden wie folgt erkannt: Systematische Suche nach Sicherheitslücken mit den Verfahren Threat Modeling, Static Analysis und Fuzzing. Identifizieren der wesentlichen, schwerwiegendsten, (remote) aus dem Internet leicht ausnutzbaren Sicherheitslücken und Bewertung der übrigen Sicherheitslücken (Priorisrung). Die entscheidenden Faktoren für diese drei Verfahren sind: Fuzzing benötigt zum Erfolg keinen Quellcode (Blackbox-Test): Die Software wird während Ihrer Ausführung untersucht. Hierzu kann die Software in einer Virtuellen Maschine oder auf einem anderen Testsystem ausgeführt werden. Wir empfehlen den sich Einsatz der drei Verfahren Threat Modeling, Static analysis und Dynamic Analysis: Fuzzing, weil sie sich ergänzen. Wir empfehlen den Einsatz von 3 7 Fuzzing Tools, weil nur ein Bündel von Fuzzern eine hinreichende Menge kritischer Sicherheitslücken identifiziert. Ist für ein konkretes Target System ein angemessener Fuzzer nicht verfügbar, entwickelt soft check spezielle Fuzzer. Für spezielle Target Systems entwickelt soft check auch spezifische Attack Strings auf der Basis selbst entwickelter Testdaten. Fuzzing wird erfolgreich auch in den Bereichen Webanwendungen, App eingesetzt sowie in Hardware. Das Bundesamt für Sicherheit in der Informationstechnik empfiehlt den Einsatz von Threat Modeling, Static Analysis und Fuzzing. Training Requirements Design Implementation Verification Release Response Threat Modeling: Security Architecture, Abuse Cases, Risk Analysis, Attack Surface Minimalisation Static Analysis: Souce Code Analysis (white box) Fuzzing Black Box & White Box Abb. 1: Lebenszyklus der Entwicklung sicherer Software 1. August 2012 Kostengünstige Identifizierung bisher nicht erkannter Sicherheitslücken Seite 2 von 9

4 2 Keine Software ohne Fehler? Software kann tatsächlich nicht fehlerfrei erstellt werden. Dies macht eine Überprüfung der Software erforderlich, wobei eine enge Bindung zur Qualitätssicherung besteht. Manuelle Überprüfungen sind angesichts des meist großen Code-Umfangs nicht praktikabel. In der Welt des traditionellen Software Testing bleiben Sicherheitslücken in der Design Phase meist unberücksichtigt und in der Implementation Phase werden (häufig ausgezeichnete) Programmierhandbücher eingesetzt. Ziele von Tests sind allein die spezifizierten Funktionalitäten. Nicht-funktionale Tests werden häufig vernachlässigt. Mit den Verfahren Threat Modeling, Static Analysis und Fuzzing können Sicherheitslücken erkannt werden, die beispielsweise die folgenden Angriffe ermöglichen: Verletzung der Zugriffsregeln Formatstring-Angriffe SQL Injections Buffer Overflows. 3 Software-Entwicklungszyklus Software wird unter Einsatz von Methoden hergestellt, die Sicherheitslücken nicht vollständig vermeiden (können) menschliche Fehler können nicht ausgeschlossen werden; selbst wenn Programmierrichtlinien vorhanden sind, werden sie nicht (vollständig) eingehalten und nicht (vollständig) kontrolliert. Dabei existieren wirkungsvolle Tools weit über klassische Verfahren des Testing hinaus, die Sicherheitslücken bereits in der Designphase identifizieren (Threat Modeling) oder spätestens in der Verifikationsphase (Fuzzing und Penetration Testing). Beim Threat Modeling werden Design-Fehler erkannt, indem z.b. Datenflussdiagramme und Angriffsbäume ausgewertet werden. Beim Fuzzing werden zur Identifizierung bisher nicht-erkannter Sicherheitslücken die Eingabeschnittstellen (Attack Surface) gerade mit solchen Eingaben attackiert, die nicht spezifiziert sind, wodurch ein Fehlverhalten der Software provoziert wird. Costs 35 x Application in the Field 15 x 6 x 1 x Threat Modeling Static Analysis Fuzzing Requirements / Design Implementation Verification / Testing Release Phase Abb. 2: Kosten der Behebung von Sicherheitslücken in den Software-Entwicklungsphasen Allzu viele Sicherheitslücken werden aber nach wie vor erst dann identifiziert, wenn Software an den Kunden ausgeliefert ist. Im Folgenden werden die Methoden zur Identifizierung von Sicherheitslücken dargestellt und einige bekannte Tools genannt. Die Kosten zur Beseitigung von Softwarefehlern, sind abhängig von deren zeitlicher Entdeckung im Software Development Lifecycle (SDLC). Werden Fehler erst nach dem Release beim Endkunden - entdeckt, steigen die Kosten je nach Untersuchung - um den Faktor 30 bis vgl. Abb. 2. Die Qualität von Softwareprodukten ist häufig auf mangelnde Ressourcen in den entwickelnden Unternehmen zurückzuführen. Zudem werden vom Markt sehr kurze Produktlebenszyklen vorgegeben. Dabei lassen sich Threat Modeling, Static Analysis und Fuzzing als marktgerechte Methoden zur Entdeckung von Softwarefehlern nutzen. 1. August 2012 Kostengünstige Identifizierung bisher nicht erkannter Sicherheitslücken Seite 3 von 9

5 Untersuchungen in Projekten von soft check zeigen, dass im Vergleich zu traditionellen Methoden dazu nur wenige Ressourcen benötigt werden. Im Rahmen des vom Bundesministerium für Bildung und Forschung an der Hochschule Bonn-Rhein-Sieg geförderten Projektes (FKZ 01 IS 09030) soft check werden über 100 weltweit verfügbare Tools zum Threat Modeling und Fuzzing analysiert und bewertet. 4 Threat Modeling Dieses proaktive und heuristische Verfahren unterstützt die methodische Entwicklung eines vertrauenswürdigen Systementwurfs oder einer Architektur in der Design Phase - sodass dies am kosteneffizientesten ist. Gleichermaßen lassen sich bereits bestehende Systementwürfe und Architekturen verifizieren, mit dem Ziel der Identifizierung, Bewertung und Korrektur von Sicherheitslücken. Threat #1 Decrypt Company Secrets and 1.1 Obtain Encrypted File 1.2 Obtain Password/Key Bribe the Sysadmin Hack the Database Brute Force Password/Key Use Keylogger Vorgehen beim Threat Modeling Abb. 3: Fehlerbaum im Threat Modeling Analyse der Dokumentation (falls vorhanden) insbesondere des Sicherheitsdesigns oder des Quellcodes. Untersuchung der Programmablaufpläne Beschreibung und Priorisierung erkannter sicherheitsrelevanter Designfehler Entwicklung von Fehlerbäumen (attack trees) - vgl. Abb. 3: Fehlerbäume im Threat Modeling Report Generation: Bericht und Vorgehensempfehlungen für erkannte Sicherheitslücken Ziel ist weiterhin das Verständnis der Sicherheitsarchitektur, das Erkennen von Designfehlern und die Minimierung möglicher Angriffspunkte (Attack Surface). Einige Threat Modeling Tools sind Microsoft Threat Analysis & Modeling, Microsoft SDL Threat Modeling Tool und Trike. Die Anzahl an gefundenen Sicherheitslücken durch Threat Modeling ist erheblich. So wurden in einem Projekt der Autoren kritische Sicherheitslücken bereits in der Designphase identifiziert, die aus dem Internet ausnutzbar wären. 5 Static Source Code Analysis Dieses Verfahren analysiert den Quellcode, ohne ihn auszuführen (im Gegensatz zu Dynamic Analysis: Fuzzing). Dabei wird in der Implementierungsphase die Konformität mit der Programmiersprache und den Programmierrichtlinien überprüft - wie ein Parser, der eine lexikalische, syntaktische und semantische Analyse des Programmcodes durchführt. Einige Static Analysis Tools sind Pixy und XDepend. 1. August 2012 Kostengünstige Identifizierung bisher nicht erkannter Sicherheitslücken Seite 4 von 9

6 6 Fuzzing Beim Fuzzing wird die Robustheit der untersuchten Software mit möglichst zielgerichteten Daten überprüft. Damit kann sporadischen Betriebsausfällen und unbeabsichtigten Datenabflüssen - den häufigsten Folgen sicherheitsrelevanter Softwarefehler - entgegengewirkt und proaktiv hohe Umsatzausfälle, Datenschutzprobleme und Reputationsschäden gemindert werden. Dazu werden beim Fuzzing Eingabeschnittstellen identifiziert, an die die Daten gesendet werden. Der Fuzz-Testing Prozess ist in der Verifikationsphase des SDLC angesiedelt - vgl. Abb. 1. Hier sollten Fehler spätestens behoben werden. Denn wenn Fehler erst später gefunden werden also nach dem Release - steigen die Kosten erheblich an siehe Abb. 2. Wurden die Eingabeschnittstellen der Zielanwendung identifiziert und die vom Fuzzer erzeugten Daten an die Zielanwendung geschickt, überwacht ein Monitoring-Tool die Zielanwendung und meldet erkannte Anomalien wie z.b. Programmabstürze, hohe CPU- oder Speicher-Auslastung etc. dem Security Analysten - vgl. Abb. 4. Test System Identification Code Coverage Input Interfaces Proprietary Developed Fuzzer Proprietary Developed Attack Strings Fuzzer Target System Target Application Target Processor ARM, AMD, IBM, Intel, PLC, Sun, Target OS Android, CardOS, JCOB, Nucleus, OS X, QNX, Unix, VxWorks, Windows, S7, Monitor/Debugger Monitor Client Expert Advice: Identification, Rating Proof of Concept: Exploits Report Abbildung 4: Fuzzing-Prozess Im Anschluss erfolgt durch den Security Experten eine Analyse, in der u.a. die Reproduzierbarkeit (Reproducibility), die Ausnutzbarkeit (Exploitability) aus dem Internet und die Schwere der Sicherheitslücke (severity) bestimmt werden. Dies ist der zeitlich aufwändigste Teilprozess des Fuzzing-Prozesses. Für das Fuzzing wird der Quellcode der Zielanwendung nicht benötigt, was die Einbeziehung externer Security Analysten vereinfacht. Je nach Typ lassen sich Fuzzer lokal und remote einsetzen. Zu den lokalen Fuzzern werden z. B. die Kommandozeilen-Fuzzer gezählt. Netzwerkbasierte Anwendungen werden remote gefuzzed. Dazu kommen Fuzzer, die Web-Applikationen und Browser fuzzen. Weiterhin können sog. Dumb und Smart Fuzzer unterschieden werden: Smart-Fuzzer testen programmgesteuert selbständig ein Zielprogramm - oftmals ohne weitere Vorbereitung oder Begleitung durch den Anwender; sie sind häufig lizenzpflichtig. Häufig ermöglichen nur Smart Fuzzer das Eindringen in das Zielprogramm und Austesten des Programmcodes. Dumb-Fuzzer können den Aufbau des Zielprogramms nicht erkennen und sie generieren nur ungesteuerte Eingabedaten. Wegen dieser fehlenden Programmsteuerung setzen sie eine erhebliche Erfahrung beim Anwender voraus; dafür sind sie häufig entgeltfrei aus dem Internet herunterladbar - vgl. Abb. 6. Fuzzing-Frameworks bieten die beste Möglichkeit, der eigenen Zielanwendung angepasste Fuzzer zu entwickeln ähnlich einem Baukasten. Der Entwicklungsaufwand ist jedoch verhältnismäßig hoch zumal für viele Anwendungen bereits fertig nutzbare Fuzzer existieren. Fuzzing Frameworks eignen sich besonders bei neuen proprietären Zielanwendungen wie z. B. neue Netzwerkprotokolle. Kommerzielle Tools zeichnen sich meist durch eine einfach bedienbare graphische Benutzeroberfläche aus. Eine Herausforderung stellt allein die Auswahl der wirkungsvollen Fuzzer aus den über 300 bekannten dar. Der Fuzzing-Erfolg hängt von der richtigen Auswahl in Abhängigkeit vom jeweiligen Zielprogramm ab. Meist wird auch nur der Einsatz von bis zu sieben Fuzzern zu einem sehr guten Ergebnis führen. 1. August 2012 Kostengünstige Identifizierung bisher nicht erkannter Sicherheitslücken Seite 5 von 9

7 Die Qualität von Fuzzern hängt im Wesentlichen von der Größe des getesteten Eingaberaums (der unendlich ist) und der Qualität der erzeugten Daten ab. Für den Fuzzing-Erfolg entscheidend ist daher die Fuzz- Datengenerierung; die Wirksamkeit der Fuzzer unterscheidet sich also maßgeblich durch den Algorithmus zur Generierung dieser Eingabedaten für das Zielprogramm. soft check kann dazu einen auf das Zielprogramm hin optimierten eigenen Datensatz einsetzen. Einige Fuzzing Tools sind AxMan, bestorm, Defensics, FileFuzz, FTPStress Fuzzer, Fuzz, Peach, SPIKE, SPIKEfile. Ein weiteres wesentliches Bewertungskriterium für Fuzzer ist die Testabdeckung (Code Coverage): Welcher Anteil des Programmcodes wurde mit den vom Fuzzer eingespeisten Daten abgedeckt? Auch dazu liegen ausgewählte Tools vor. Fixkosten Automatische Fuzzer Manuelle Fuzzer Variable Kosten / Benötigte Expertise Abb. 5: Divergenz Produktkosten - Personalaufwand 7 Beispielhafte Fuzzing-Bereiche Webanwendungen Eine Besonderheit in der Softwaresicherheit stellen Webanwendungen dar. Die Dynamik von Webseiten hat in den letzten Jahren stark zugenommen. Diese Dynamik ermöglicht die Interaktion mit Nutzern und das Bereitstellen von webbasierten Diensten. Für ein Unternehmen bedeutet das i. d. R. eine Vereinfachung von Geschäftsprozessen, erhebliche Kosteneinsparungen und Wettbewerbsvorteile. Selbst Dienste, die wertvolle Unternehmens-interne Daten beinhalten sind aufgrund von veränderten Anforderungen an die Nutzung bzw. an Geschäftsprozesse aus unsicheren Netzen wie dem Internet erreichbar. So bieten ERP Systeme die vor einigen Jahren lediglich aus dem internen Firmennetzwerk erreichbar waren Schnittstellen zum Internet (vgl. SAP Business Server Pages). Dieser Trend birgt ein hohes Sicherheitsrisiko für Unternehmen wie auch Anwender. Webanwendungen haben gegenüber herkömmlicher Software eine wesentlich höhere Angriffsfläche, da eine Vielzahl von Verfahren/Techniken eingesetzt werden (Datenbankinteraktionen, verschiedene Programmier- und Skriptsprachen, Webserver, etc.). Darüber hinaus bietet das HTTP-Protokoll aufgrund der offenen Request/Response - Kommunikation hervorragende Analysemöglichkeiten. Aufgrund der aufgezeigten sensiblen Eigenschaften ist eine umfassende Analyse der Webanwendung auf Design-, Implementierungs- und Konfigurationsfehler von zentraler Bedeutung. Wir empfehlen als umfangreiche Sicherheitsanalyse das Testen der Webanwendung mittels Threat Modeling, Static Analysis und Fuzzing, um äquivalent zu herkömmlicher Software ein größtmögliches Sicherheitsniveau zu gewährleisten. Zusätzlich sollte ein Penetration Test des Web-Servers durchgeführt werden. Das Kompromittieren des Web-Servers bedeutet ebenso das Beeinträchtigen von Vertraulichkeit, Integrität und Authentizität der gesamten Webanwendung und den zugrundeliegenden Daten. So ist es Angreifern möglich, alle Daten der Webanwendung einzusehen, diese zu verändern oder gar eigene Schadsoftware zu installieren. Die aufgezeigten Angriffsmöglichkeiten bewirken i. d. R. langfristige monetäre Schäden und können das Image des Unternehmens erheblich beeinträchtigen. 1. August 2012 Kostengünstige Identifizierung bisher nicht erkannter Sicherheitslücken Seite 6 von 9

8 Embedded Systems Eingebettete Systeme sind in ein größeres Produkt integrierte informationsverarbeitende Systeme, die meist nicht direkt wahrgenommen werden. Beispiele sind Router, speicherprogrammierbare Steuerungen und Unterhaltungsgeräte (Spiele) etc. Sicherheitslücken in eingebetteten Systemen haben weitreichende Konsequenzen. Angefangen von Routern, im Stromzähler des Smart Grid bis hin zu Anlagen zur Überwachung und Steuerung in der Elektro- Gas-, Wasserund Ölversorgung eingesetzt werden vgl. stuxnet. Ein eingebettetes System besteht sowohl aus Software als auch Hardware. Durch die Trendwende zum Ubiquitous Computing also der Allgegenwärtigkeit der rechnergestützten Informationsverarbeitung sind die früher autarken Systeme nun miteinander vernetzt. Darüber hinaus verfügen komplexe eingebettete Systeme über ein eigenständiges spezielles Betriebssystem (embedded OS), eine Webschnittstelle oder unterstützen auch Hochsprachen. Dadurch ergeben sich eine Vielzahl an Eingabeschnittstellen, die zum Fuzzing genutzt werden können. Dennoch ist die Identifizierung der Eingabeschnittstellen eine Herausforderung beim Fuzzen eingebetteter Systeme. Nicht jeder Fuzzer versteht jede Eingabeschnittstelle. Der Fuzzer kann dabei als externe Anwendung arbeiten oder als Anwendung auf dem Testsystem. In jedem Fall steht er logisch zwischen dem Testsystem und dem eingebetteten System. Der Embedded-Fuzzer agiert als Bridge. Eine weitere Herausforderung stellt das Monitoring dar. Nicht immer ist es möglich einen Monitor auf dem eingebetteten System zu installieren, es erfolgen auf Request-Telegrammen keine Respone-Telegramme, die Kommunikation ist unidirektional etc. In solchen Szenarien ist nur ein manuelles Monitoring (durch den Experten) möglich; soft check entwickelt auch selbst Fuzzer und generiert spezifische Attack Strings (Testdaten). Embedded Fuzzing eignet sich hervorragend zur Fehleranalyse eingebetteter Systeme. Die meisten heute eingesetzten Verfahren zur Fehleranalyse eingebetteter Systeme erfolgen nur über Fehlersimulationen. Diese sind sehr zeitaufwendig und bergen die Gefahr der Unvollständigkeit. Durch Analog-Fuzzer ist eine Fehlerinjektionen vollständig auf Hardware-Ebene realisierbar. App-Fuzzing Das Sicherheitsniveau von Apps für Android, ios und OSX oder ähnlichen Betriebssystemen für Smart Devices (Smartphones etc.) entspricht häufig nicht den Anwendervorstellungen; Apps ermöglichen im Einzelfall das Auslesen aller Daten (Adressverzeichnis, s, SMS, MMS, Anrufer ) des smart Devices und auch das Abhören und Mitschneiden von Gesprächen und auch den uneingeschränkten Zugriff auf (kostenpflichtige) Onlinedienste - ohne einen PC oder ein Notebook/Laptop zu nutzen. Mit Threat Modeling, Static Analysis und insbesondere Fuzzing der automatischen Erzeugung zielgerichteter Eingaben - können Programmierfehler und Sicherheitslücken identifiziert werden. Fuzzing bietet bei Apps auf jedem Betriebssystem und jedem Smartphone eine sehr kosteneffiziente Möglichkeit um automatisiert Fehler und Sicherheitslücken zu finden die von Angreifern unbemerkt ausgenutzt werden können. Der Fuzzing-Prozess ist bis auf gewisse Einschränkungen durch die Hardware des Smartphones äquivalent zu der bei herkömmlicher Hard- und Software die auf Desktop-Rechnern läuft. Hier muss ggf. eine eigene Monitorlösungen entwickelt werden. 8 Spezielle Anwendungen Entwicklung proprietärer Fuzzer Ist für ein konkretes Target-System ein angemessener Fuzzer nicht verfügbar, entwickelt soft speziellen Fuzzer. check einen Proprietäre Attack Strings Für spezielle Target Systems entwickelt softscheck auch spezifische Attack-Strings auf der Basis selbstentwickelter Testdaten. 9 Ergebnisse Mit Fuzzing und Threat Modeling stehen Tool-gestützte Verfahren zur Detektion von insbesondere sicherheitsrelevanten Softwarefehlern zur Verfügung. So kann Zero-Day-Angriffen, welche eine der zwanzig am häufigsten auftretenden Angriffsformen sind, entgegenwirkt und die Anwendungssicherheit effizient und marktgerecht gesteigert werden. Eine Zusammenfassung der folgenden 6 Ergebnisse: Systematische Suche und auch erfolgreiche (!) Identifizierung der wesentlichen Sicherheitslücken. Und zwar in jeder Software: Individualsoftware, Standardsoftware wie ERP, CRM und auch unternehmensspezifische Ergänzungen, Betriebssysteme, embedded Systems etc. Kein Quellcode wird zum Threat Modeling und Fuzzing benötigt - ausführbare Dateien bzw. das Design reichen völlig aus: Black-Box. 1. August 2012 Kostengünstige Identifizierung bisher nicht erkannter Sicherheitslücken Seite 7 von 9

9 Nur bei Einsatz von Threat Modeling und Fuzzing können Design- und Implementierungsfehler sowie Sicherheitslücken identifiziert werden. Erst bei Einsatz mehrerer Tools einer Klasse (bei Fuzzern z.b. drei bis sieben verschiedene Fuzzer) kann ein Optimum an bisher nicht-erkannten Sicherheitslücken identifiziert werden. Mit ausgewählten Code-Coverage-Tools kann der Erfolg des Fuzzing bewertet werden. soft check kann dazu einen auf das Zielprogramm hin optimierten eigenen Datensatz einsetzen. Bei Softwareherstellern und Endanwendern kann durch die Kombination der erläuterten Verfahren und die Integration in den SDLC ein höheres Return on (Security) Investment erreicht werden. Zudem kann proaktiv die Qualität der Software gesteigert und können Markteinführungszeiten reduziert und Kosten gespart werden. Neben der Kostenersparnis kann die Reputation des Softwareherstellers durch sicherere Software gesteigert werden. Threat-Modeling, Static-Analysis und Fuzzing können für alle Anwendungsarten eingesetzt werden - von Protokollen bis hin zur Individualsoftware und Webapplikationen. Zur Unterstützung bei einer bedarfsgerechteren Auswahl von geeigneten Tools hat soft check eine Taxonomie entwickelt. Method No. Vulnerabilities No. Tools used Architecture Analysis: Threat Modeling Static Source Code Analysis Penetration Testing (8) 4-9 Dynamic Analysis: Fuzzing 27 > 60 Abb. 6: Erfolge bei der Identifizierung von Sicherheitslücken Die Anzahl der mit Fuzzing identifizierten Sicherheitslücken (meist ohne Vorliegen des Quellcode) ist enorm. Dies ist der Grund für die zunehmende Verbreitung und Beliebtheit der Methode. So wurden in einem Projekt des Autors in bereits an Kunden ausgelieferter Standardsoftware 50 kritische (bisher nicht veröffentlichte) Sicherheitslücken identifiziert, die aus dem Internet ausnutzbar waren - vgl. Abb. 7. Dies obwohl beim Hersteller ein umfangreiches Richtlinienwerk auch hinsichtlich der Programmierung sicherer Software existiert. 10 Die erfolgreichsten Verfahren zur Identifizierung von Sicherheitslücken Threat Modeling Sicherheitslücken werden bereits in der Designphase identifiziert. Systematische und Tool-gestützte Verfahren. Sicherheitslücken können priorisiert werden: Aus dem Internet ausnutzbar und/oder geringer Aufwand für den Angreifer. Static Source Code Analysis Tool-gestütztes Code Reading. Fuzzing Black-Box - kein Quellcode erforderlich - ausführbare Dateien reichen völlig aus! Gängige Verfahren - seit mehr als 5 Jahren bei den weltweit größten Softwarehäusern im Einsatz - auch in KMU. soft check unterstützt darüber hinaus mit den weiteren Verfahren: Security by Design: Entwicklung von Sicherheitsarchitekturen für Software Penetration Testing u.a. zur Überprüfung auf bereits bekannte Sicherheitslücken Explorative Testing und manuelles Code Auditing. Und letztlich identifizieren und analysieren wir auch Covert Functions undokumentierte, verdeckte Funktionen u.a. auch auf Smartphones und mobile Devices. 1. August 2012 Kostengünstige Identifizierung bisher nicht erkannter Sicherheitslücken Seite 8 von 9

10 Weiterführende Literatur Beyond Security (Ed.): Beyond Security (Ed.): Codenomicon (Ed.): Black Box Testing. McLean Beyond Security introduces 80/20 rule for 'smart' blackbox testing in new version of bestorm. McLean Buzz on Fuzzing. Cupertino Fox, D.: Fuzzing. DuD 30, 2006, 12, Peter, M.; Karen, S.; Romanosky, S.: Complete Guide to Complete Guide to the Common Vulnerability Scoring System Version 2.0 Gaithersburg Pohl, H.: Zur Technik der heimlichen Online-Durchsuchung. DuD 31, 9, Pohl, H.: Kostengünstige Identifizierung von Sicherheitslücken mit Threat Modeling und Fuzzing. KES Zeitschrift für Informationssicherheit, Heft 2 / 2010 Rathaus, N.; Evron, G.: Open Source Fuzzing Tools. Amsterdam Doyle, F.; Fly, R.; Jenik, R.; Manor, D. Miller, C.; Naveh, Y.: Open Source Fuzzing Tools. Amsterdam 2007 Sutton, M,; Greene, A.; Amini, P.: Fuzzing - Brute Force Vulnerability Discovery. New York Takanen, A.; Demott, J.D.; Miller, C.: Fuzzing For Software Security Testing And Quality Assurance. Norwood August 2012 Kostengünstige Identifizierung bisher nicht erkannter Sicherheitslücken Seite 9 von 9

11 Prof. Dr. Hartmut Pohl Geschäftsführender Gesellschafter soft check GmbH Köln www. soft check.com Büro: Bonner Str Sankt Augustin Tel.: +49 (2241) Mobil: +49 (172) Fax: +49 (2241) check.com