Kostengünstige Identifizierung bisher nicht-erkannter Sicherheitslücken

White Paper Software-Sicherheit Kostengünstige Identifizierung bisher nicht-erkannter Sicherheitslücken Darstellung der 3 Verfahren Threat Modeling, Static Source Code Analysis und Dynamic Analysis: Fuzzing Hartmut Pohl 1 1 Prof. Dr. Hartmut Pohl, softscheck GmbH, Köln

Inhalt 1 Keine Software ohne Fehler... 5 2 Software-Entwicklungszyklus... 5 3 Threat Modeling... 6 4 Static Source Code Analysis... 7 5 Fuzzing... 7 Beispielhafte Fuzzing-Bereiche... 9 Webanwendungen... 9 Embedded Systems... 10 App-Fuzzing... 10 Spezielle Anwendungen... 10 Entwicklung proprietärer Fuzzer... 10 Proprietäre Attack Strings... 10 6 Ergebnisse... 11 7 Die erfolgreichsten Verfahren zur Identifizierung von Sicherheitslücken... 12 Static Source Code Analysis... 12 Fuzzing... 12 Weiterführende Literatur... 13 Januar 2013 Kostengünstige Identifizierung bisher nicht erkannter Sicherheitslücken Seite 2 von 14

Management Summary Angesichts der beiden Fakten: Software kann nicht fehlerfrei erstellt werden; macht dies eine Überprüfung der Software erforderlich und kein (erfolgreicher) Angriff ohne Ausnutzung einer Sicherheitslücke bieten wir "Security Testing as a Service" als vollständigen Prozess an, um das Sicherheitsniveau der Software unserer Kunden zu steigern. Zur Identifizierung bisher nicht-erkannter Sicherheitslücken arbeiten wir dazu erfolgreich Tool-gestützt mit den auch vom Bundesamt für Informationssicherheit (BSI) unterstützten folgenden 7 Verfahren: 1. Security by Design: Entwicklung von Sicherheitsarchitekturen für Software 2. Threat Modeling: Überprüfung der Sicherheitsarchitektur 3. Dynamic Analysis Fuzzing: Test der ausführbaren, kompilierten Datei kein Quellcode nötig. Wir setzen im Einzelfall über 50 Tools aus den weltweit mehr als 300 verfügbaren ein: Jedes Fuzzing-Tool identifiziert andere Sicherheitslücken! 4. Static Source Code Analysis: Überprüfung von Implementierungsfehlern 5. Penetration Testing: Zur Überprüfung auf bereits bekannte Sicherheitslücken 6. Explorative Testing und manuelles Code Auditing. 7. Und letztlich identifizieren und analysieren wir auch Covert Functions undokumentierte, verdeckte Funktionen u.a. auch auf Smartphones und mobile Devices Im folgenden sollen insbesondere die 3 erfolgreichen Verfahren Threat Modeling (Design Phase), Static Source Code Analysis (Implementation Phase) und Dynamic Analysis: Fuzzing (Verifikation Phase) dargestellt werden; mit diesen Verfahren werden insbesondere alle bisher nicht-veröffentlichten Sicherheitslücken (Zero-Day-Vulnerabilities) identifiziert. Der Einsatz dieser 3 Verfahren wird umso wirkungsvoller und kostengünstiger je früher in der Software-Entwicklung Sicherheitslücken identifiziert werden möglichst also beginnend in der Designphase. Am teuersten wird es, wenn die Software schon ausgeliefert ist (Release Phase) und erst dann korrigiert wird - vgl. Abb. 1. Zudem lassen sich diese 3 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 Industrial Control Systems (ICS) (auch proprietärer Systeme) Manufacturing Execution Systems (MES), Produktionsleitsysteme, SCADA (Leittechnik und systeme), SPS bis zur Feldebene, Cyber Physical Systems (CPS), Industrie 4.0, in Apps und Applets für smart and mobile Devices, im Cloud Computing und auch in Hardware. Im Bereich Smart Grid / M2M haben wir erfolgreich Energy Management Systeme - EMS und Machine-to-Machine Communication in einem Smart Meter Gateway (SMGW) abgesichert. Der Einsatz herkömmlicher Verfahren zur Behebung von Fehlern und insbesondere bisher nicht erkannter Sicherheitslücken ist dagegen sehr kostenaufwändig - viele Sicherheitslücken werden daher nicht oder 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, Static Source Code Analysis und Dynamic Analysis: Fuzzing vergleichsweise sehr kostengünstig durchgeführt werden kann auch wenn sich die Software schon auf dem Markt befindet. Neben der Identifizierung bisher nicht-erkannter Sicherheitslücken werden diese bewertet (Rating), um entscheiden zu können, ob alle identifizierten Sicherheitslücken behoben werden sollen oder ob auf das Patchen einiger verzichtet werden kann (Priorisierung). Die entscheidenden Faktoren für diese drei Verfahren sind: Wir empfehlen den Einsatz der drei Verfahren Threat Modeling, Static Source Code Analysis und Dynamic Analysis: Fuzzing, weil sie sich erfolgreich ergänzen. Dynamic Analysis: 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 Einsatz von bis zu 50 Fuzzing-Tools, weil nur ein derart großes 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 softscheck spezielle Fuzzer. Für spezielle Target Systems entwickelt softscheck auch spezifische Attack Strings auf der Basis selbst-entwickelter Testdaten. Januar 2013 Kostengünstige Identifizierung bisher nicht erkannter Sicherheitslücken Seite 3 von 14

Security by Design Architecture Analysis Threat Modeling Static Source Code Analysis Explorative Testing: Manual Auditing Penetration Testing Dynamic Analysis: Fuzzing Secure Design Secure Implementation Requirements Product Security Design Implementation Verification Release Abb. 1: softscheck Security Testing Process Mit der Identifizierung und Behebung bisher nicht-erkannter Sicherheitslücken kann sporadischen Betriebsausfällen und unbeabsichtigten Datenabflüssen - den häufigsten Folgen sicherheitsrelevanter Softwarefehler - entgegengewirkt werden und so können proaktiv hohe Umsatzausfälle, Datenschutzprobleme und Reputationsschäden gemindert werden. Mit den von uns sowohl Tool-gestützt als auch mit Manual Auditing eingesetzten Methoden sind wir sehr erfolgreich. In einer Stichprobe aus 40 Projekten haben wir durchschnittlich insgesamt 156 Sicherheitslücken identifiziert: Method No. Vulnerabilities No. Tools used Architecture Analysis: Threat Modeling 112 1-2 Static Source Code Analysis 17 3-5 Penetration Testing (76) 4 Dynamic Analysis: Fuzzing 27 > 60 Summe 156 > 70 Das Bundesamt für Sicherheit in der Informationstechnik empfiehlt den Einsatz von Threat Modeling, Static Source Code Analysis und Dynamic Analysis: Fuzzing. softscheck hat in den geprüften Zielprogrammen mit dem hier dargestellten Security Testing Process tatsächlich alle bis dahin nicht-bekannten Sicherheitslücken identifiziert. Nach diesen Sicherheitsprüfungen wurden also keine anderen / weiteren Sicherheitslücken mehr erkannt! Januar 2013 Kostengünstige Identifizierung bisher nicht erkannter Sicherheitslücken Seite 4 von 14

1 Keine Software ohne Fehler Software kann 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 Source Code 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. 2 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. Angriffsbäume und Datenflussdiagramme 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. Allzu viele Sicherheitslücken werden aber nach wie vor erst dann identifiziert, wenn die Software an den Kunden ausgeliefert ist. Im Folgenden werden die Methoden zur Identifizierung von Sicherheitslücken dargestellt und einige bekannte Tools genannt. Wie dargestellt sind die Kosten zur Beseitigung von Softwarefehlern 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 100 - vgl. Abb. 2. 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 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 Source Code Analysis und Fuzzing als marktgerechte Methoden zur Entdeckung von Softwarefehlern nutzen. Januar 2013 Kostengünstige Identifizierung bisher nicht erkannter Sicherheitslücken Seite 5 von 14

Untersuchungen in Projekten von soft check zeigen, dass im Vergleich zu traditionellen Methoden dazu nur wenige Ressourcen benötigt werden. Mittels Threat Modeling, Static Source Code Analysis und Fuzzing werden Softwarehersteller, Nutzer und Endanwender, die Standardsoftware anpassen (Customizing), in die Lage versetzt, Software-Tests wirkungsvoller und kostengünstiger mit den für ihre Aufgabenstellung geeigneten Tools durchzuführen und dadurch die Software sicherer zu machen: Mit Hilfe dieser Methoden lassen sich bisher nicht erkannte Fehler und Sicherheitslücken erkennen. 3 Threat Modeling Dieses systematische und proaktive Verfahren unterstützt die methodische Entwicklung eines vertrauenswürdigen Systementwurfs oder einer Architektur in der Design Phase. Gleichermaßen lassen sich bereits bestehende Systementwürfe und Architekturen verifizieren, mit dem Ziel der Identifizierung, Bewertung und Korrektur von Sicherheitslücken. Bedrohung #1 Unternehmensdaten entschlüsseln and Bedrohung 1.1 Verschüsselte Datei untersuchen Bedrohung 1.2 Passwort / Schlüssel Bedrohung 1.1.1 Bestechung des Administrators Bedrohung 1.1.2 Datenbank angreifen Bedrohung 1.2.1 Brute Force Angriff Bedrohung 1.2.2 Keylogger Abb. 3: Fehlerbaum im Threat Modeling Vorgehen beim Threat Modeling Analyse der Dokumentation (soweit vorhanden) insbesondere des Sicherheitsdesigns oder des Quellcodes. Untersuchung der Programmablaufpläne Beschreibung und Priorisierung bereits erkannter sicherheitsrelevanter Designfehler Ziel ist das Verständnis der Sicherheitsarchitektur, das Erkennen von Designfehlern und die Minimierung möglicher Angriffspunkte (Attack Surface). Entwicklung von Fehlerbäumen (Attack Trees) - vgl. Abb. 3: Fehlerbäume im Threat Modeling Report Generation: Bericht und Vorgehensempfehlungen für identifizierte Sicherheitslücken Einige Threat Modeling Tools sind Microsoft Threat Analysis & Modeling, Microsoft SDL Threat Modeling Tool und Trike. Die Anzahl identifizierter Sicherheitslücken durch Threat Modeling ist erheblich. So wurden in einem Projekt der Autoren ca. 100 (!) kritische, aus dem Internet ausnutzbare, Sicherheitslücken bereits in der Designphase identifiziert. Januar 2013 Kostengünstige Identifizierung bisher nicht erkannter Sicherheitslücken Seite 6 von 14

Rating the Vulnerabilities critical 1 high 29 medium 26 low 1 0 5 10 15 20 25 30 35 Number identified Vulnerabilities Abb. 4: Mit Threat Modeling erkannte Sicherheitslücken in Standardsoftware 4 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 Source Code Analysis Tools sind Pixy und XDepend. 5 Fuzzing Beim Fuzzing wird die Robustheit der untersuchten Software mit möglichst zielgerichteten Daten überprüft. Dazu werden beim Fuzzing Eingabeschnittstellen identifiziert, die an 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 noch später gefunden werden also nach dem Release - steigen die Kosten erheblich an siehe Abb. 2. Test System Identification Code Coverage Input Interfaces Proprietary Developed Fuzzer Proprietary Developed Attack Strings Fuzzer 0000 0000 1111 1111 Target System 1 Target Application 2 Encryption I/A DB Target Processor ARM, AMD, IBM, Intel, Nvidia, PLC, Power PC, Qualcomm, Sun, Snapdragon, 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 Patch, Fix Abb. 5: Fuzzing-Prozess Januar 2013 Kostengünstige Identifizierung bisher nicht erkannter Sicherheitslücken Seite 7 von 14

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. 5. 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 Fuzzingprozesses. 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, an die eigene 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. neuen Netzwerkprotokollen. 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 softscheck Fuzzing-Erfolg hängt von der richtigen Auswahl in Abhängigkeit vom jeweiligen Zielprogramm ab. Meist wird auch nur der Einsatz von bis zu 50 Fuzzern zu einem sehr guten Ergebnis führen. 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. softscheck 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. Fixkosten Automatische Fuzzer Manuelle Fuzzer Variable Kosten / Benötigte Expertise Abb. 6: Divergenz Produktkosten Personalaufwand 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. Januar 2013 Kostengünstige Identifizierung bisher nicht erkannter Sicherheitslücken Seite 8 von 14

Beispielhafte Fuzzing-Bereiche Webanwendungen Eine Besonderheit 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 die Bereitstellung webbasierter Dienste. 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 veränderter Anforderungen an die Nutzung bzw. an Geschäftsprozesse aus unsicheren Netzen (z.b. Internet) erreichbar. So bieten heutzutage 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 und Anwender. Webanwendungen haben gegenüber herkömmlicher Software eine wesentlich höhere Angriffsfläche, da eine Vielzahl von Verfahren/ Techniken eingesetzt werden (Datenbankinteraktionen, mehrere Programmier- und Skriptsprachen, Webserver, etc.). Darüber hinaus bietet das HTTP-Protokoll aufgrund der offenen Request/Response - Kommunikation hervorragende Analysemöglichkeiten. Aufgrund der aufgezeigten 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 Source Code Analysis und Dynamic Analysis: 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. Januar 2013 Kostengünstige Identifizierung bisher nicht erkannter Sicherheitslücken Seite 9 von 14

Embedded Systems Eingebettete Systeme sind in ein 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 die in der Elektro- Gas-, Wasser- und Ölversorgung eingesetzt werden vgl. stuxnet. Eingebettete Systeme bestehen sowohl aus Software als auch Hardware. Durch die Trendwende zum Ubiquitous Computing also der Allgegenwärtigkeit der rechnergestützten Informationsverarbeitung wie in der Industrie 4.0 geplant sind die früher autarken Systeme nun miteinander vernetzt. Darüber hinaus können komplexe eingebettete Systeme über ein eigenständiges spezielles Betriebssystem (embedded OS) und eine Webschnittstelle verfügen 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 derartigen Szenarien ist nur ein manuelles Monitoring (durch den Experten) möglich; softscheck 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, E-Mails, SMS, MMS, Anrufer ) des Smart Devices 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 Source Code Analysis und insbesondere Dynamic Analysis: Fuzzing der automatischen Erzeugung zielgerichteter Eingaben - können Programmierfehler und Sicherheitslücken identifiziert werden. Fuzzing bietet bei App s 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. Ggf. muss hier nur eine eigene Monitorlösungen entwickelt werden. Spezielle Anwendungen Entwicklung proprietärer Fuzzer Ist für ein konkretes Target-System ein angemessener Fuzzer nicht verfügbar, entwickelt softscheck einen speziellen Fuzzer. Proprietäre Attack Strings Für spezielle Target Systems entwickelt softscheck auch spezifische Attack-Strings auf der Basis selbstentwickelter Testdaten. Januar 2013 Kostengünstige Identifizierung bisher nicht erkannter Sicherheitslücken Seite 10 von 14

6 Ergebnisse Mit Threat Modeling und Dynamic Analysis: Fuzzing stehen Tool-gestützte Verfahren zur Identifizierung insbesondere sicherheitsrelevanter Softwarefehler 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. Die Vorteile sind folgende: 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. 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 (z.b. bis zu 50 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. softscheck 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, 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 Source Code 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 das Projekt softscheck eine Taxonomie entwickelt, die gesondert veröffentlicht wird. Bewertung der Sicherheitslücken Kritisch 5 Hoch 6 Mittel 26 Niedrig 1 Undefiniert 6 0 5 10 15 20 25 30 Identifizierte Sicherheitslücken Abb. 7: Mit Fuzzing erkannte Sicherheitslücken in Standardsoftware 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 in bereits an Kunden ausgelieferter Standardsoftware 5 kritische, 6 hochbewertete und 26 mittel-bewertete (bisher nicht unverö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. Januar 2013 Kostengünstige Identifizierung bisher nicht erkannter Sicherheitslücken Seite 11 von 14

7 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. Januar 2013 Kostengünstige Identifizierung bisher nicht erkannter Sicherheitslücken Seite 12 von 14

Weiterführende Literatur Beyond Security (Ed.): Beyond Security (Ed.): Codenomicon (Ed.): Black Box Testing. McLean 2008. http://www.beyondsecurity.com/black-boxtesting.html Beyond Security introduces 80/20 rule for 'smart' blackbox testing in new version of bestorm. McLean 2006. http://www.beyondsecurity.com/press/2006/press12090601.html Buzz on Fuzzing. Cupertino 2007. http://www.codenomicon.com/products/buzz-onfuzzing.shtml Fox, D.: Fuzzing. DuD 30, 2006, 12, 798. 2006. Peter, M.; Karen, S.; Romanosky, S.: Complete Guide to Complete Guide to the Common Vulnerability Scoring System Version 2.0 Gaithersburg 2007 http://www.first.org/cvss/cvss-guide.pdf Pohl, H.: Zur Technik der heimlichen Online-Durchsuchung. DuD 31, 9, 2007. http://www.softscheck.com/publications/pohl_technik_der_online_durchsuchung_ DuD_9_07_final_.pdf Pohl, H.: Pohl, H.: Pohl, H.: Pohl, H.: Kostengünstige Identifizierung von Sicherheitslücken mit Threat Modeling und Fuzzing. KES Zeitschrift für Informationssicherheit, Heft 2 / 2010 http://www.softscheck.com/publications/pohl%20kosteng%c3%bcnstige%20ident ifizierung%20von%20sicherheitsl%c3%bccken%20110419.pdf Fuzzelarbeit Identifizierung bisher nicht-erkannter Sicherheitslücken und Softwarefehler mit Dynamic analysis: Fuzzing. http://www.softscheck.com/publications/profdrhartmutpohl_identifizierung_unbek annter_sicherheitsluecken_und_software-fehler_durch_fuzzing_kes20115.pdf Ihre Strategie ist falsch, Teil I und II: Security in Industrial Control Systems (ICS) a+szeitschrift für Automaten und Security Heft 3 und 4, 2012 http://www.softscheck.com/publications/security%20in%20industrial%20control% 20Systems%20-%20Ihre%20Strategie%20ist%20falsch.pdf Smart Meters kommen mit Sicherheit. newsline Das Magazin der BITKOM Akademie Dezember 2012 http://www.softscheck.com/publications/bitkomnewsline_s22-23.pdf Rathaus, N.; Evron, G.: Open Source Fuzzing Tools. Amsterdam 2007. 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 2007. Takanen, A.; Demott, J.D.; Miller, C.: Fuzzing For Software Security Testing And Quality Assurance. Norwood 2008 Januar 2013 Kostengünstige Identifizierung bisher nicht erkannter Sicherheitslücken Seite 13 von 14

Prof. Dr. Hartmut Pohl Geschäftsführender Gesellschafter soft check GmbH Köln www. soft check.com Büro: Bonner Str. 108. 53757 Sankt Augustin Tel.: +49 (2241) 255 43-0 Mobil: +49 (172) 9437-329 Fax: +49 (2241) 255 43-29 Hartmut.Pohl@soft check.com