Autor: Axel Wintsche, Philotech Die Sicherheit von Software ist ein Kriterium, welches immens an Bedeutung gewonnen hat, sich aber nur unzureichend als Anforderung formulieren und testen l\u00e4sst. Eine Teststrategie wie Fuzzing bietet allerdings eine M\u00f6glichkeit, automatisiert die Robustheit von Software zu testen und damit die Sicherheit zu erh\u00f6hen. Hier beschreiben wir, was Fuzzing ausmacht, welche H\u00fcrden es beim Testen von Embedded Software gibt sowie m\u00f6gliche L\u00f6sungsans\u00e4tze.<\/strong><\/p>\n Das V-Model ist ein klassisches Beispiel daf\u00fcr, wie sich Anforderungen aus den verschiedenen Phasen der Softwareentwicklung durch geeignete Testverfahren pr\u00fcfen lassen. Und auch bei heutzutage oft verwendeten inkrementellen agilen Methoden gibt es meist eine enge Verzahnung zwischen Entwicklung und Test, mit dem Ziel, die Qualit\u00e4t zu steigern.<\/p>\n Um die Sicherheit von Software zu erh\u00f6hen, k\u00f6nnen entsprechende Methoden bei Entwicklung und Tests angewandt werden, mit dem Unterschied, dass sich das Kriterium Sicherheit nur unzureichend als Anforderung formulieren und testen l\u00e4sst. Selbst wenn durch eine umfassende Bedrohungsmodellierung entsprechende Anforderungen abgeleitet und von der Software erf\u00fcllt werden, k\u00f6nnen sich durch neue, bisher unbekannte Bedrohungen nicht erf\u00fcllte Anforderungen ergeben. Diese F\u00e4lle lassen sich durch entsprechendes Incidence Response Management behandeln. Neue Bedrohungen, also Situationen, die nicht durch Anforderungen spezifiziert wurden, lassen sich aber auch proaktiv durch entsprechende Testverfahren, wie z.B. Fuzzing, identifizieren.<\/p>\n Sichere Software ist daher als ein Prozess zu verstehen, welcher durch Einsatz verschiedener Methoden und Verfahren vom Entwurf \u00fcber die Implementierung bis zur Auslieferung und Wartung gelebt werden muss. Als Beispiele sind hier der SDL (Secure Development Lifecycle) von Microsoft und die Ressourcen des Open Web Application Security Project (kurz OWASP) zu nennen – beide empfehlen den Einsatz von Fuzzing. Welche Konsequenzen Schwachstellen in Software eingebetteter Systeme haben k\u00f6nnen, bewiesen verschiedene Untersuchungen von Sicherheitsforschern – ob erfolgreiche Hacks zum Fernsteuern von Autos [1,2], das Manipulieren von Herzschrittmachern und anderer Medizintechnik [3] oder aufgedeckte Sicherheitsl\u00fccken und Angriffe auf Infrastruktur [4,5]. Die Notwendigkeit, einen Security-Testprozess auch f\u00fcr diese Systeme zu etablieren, ist daher gro\u00df.<\/p>\n Fuzzing ist eine Methode, mit der Software durch ung\u00fcltige oder zuf\u00e4llige Eingaben getestet wird, um ein Fehlverhalten zu provozieren. In ihrer simpelsten Form wird durch Fuzzing eine zuf\u00e4llige Abfolge von Bits erzeugt oder von einer bestehenden Bitfolge eine beliebige Anzahl Bits zuf\u00e4llig ver\u00e4ndert und diese als neue Eingabe f\u00fcr die zu testende Software verwendet. Da die allermeisten auf diese Weise erzeugten Eingaben keiner formalen Anforderung entsprechen, l\u00e4sst sich vor allem testen, wie stabil die Software mit fehlerhaften Eingaben umgeht. Fuzzing Tests zielen also auf die Robustheit von Software gegen\u00fcber unerwarteten Eingaben ab. Ein Kriterium f\u00fcr Robustheit ist z.B., dass die Software zu jeder Zeit in einem definierten Zustand ist und nicht etwa abst\u00fcrzt. Prinzipiell l\u00e4sst sich so jede datenverarbeitende Software oder Softwarekomponente mittels Fuzzing testen.<\/p>\n Fuzzing besteht im Wesentlichen aus drei aufeinander folgenden Schritten: 1) Daten generieren, 2) Daten bereitstellen und 3) Monitoring der Software. Diese Schritte sind unabh\u00e4ngig voneinander, werden aber oft in einer Schleife ausgef\u00fchrt. H\u00e4ufig werden dieselben Fehler mehrfach gefunden, so dass am Ende eines Fuzzing-Tests sinnvollerweise gefundene Fehler zusammengefasst werden (Bug Triage).<\/p>\n Dies ist der eigentliche Fuzzing-Prozess, in welchem die Testdaten erzeugt werden. Man unterscheidet hier zwischen den zwei Methoden „Generieren“ und „Mutieren“. Beim Generieren werden anhand einer Spezifikation oder eines Modells Testdaten erzeugt und bei Inhalt und Struktur zuf\u00e4llige \u00c4nderungen vorgenommen. Werden hingegen bestehende Daten mit zuf\u00e4lligen \u00c4nderungen versehen, wird dies Mutieren genannt. Beide Varianten kommen in unterschiedlichen Szenarien zum Einsatz.<\/p>\n Die gefuzzten Daten werden anschlie\u00dfend an die zu testende Software \u00fcbergeben, je nach Art der Eingabeschnittstelle z.B. als Parameter beim Programmaufruf, als Datei oder in Form einer Netzwerknachricht.<\/p>\n Fehler bei der Ausf\u00fchrung der Software werden durch das Monitoring ermittelt. Dies kann von der Analyse der R\u00fcckgabewerte bis hin zur Nutzung von Debuggern reichen, welche den internen Zustand detektieren k\u00f6nnen. Die Art des Monitoring entscheidet, welche Fehler \u00fcberhaupt detektiert werden k\u00f6nnen.<\/p>\n Fuzzing kann als Blackbox- und als Whitebox-Test eingesetzt werden. Programme f\u00fcr Blackbox-Fuzzing sind oft einfacher zu konfigurieren und zu automatisieren und meist universell einsetzbar. Sie finden tendenziell aber eher simple Fehler (Dumb Fuzzing). Sind Spezifikation oder gar Quellcode verf\u00fcgbar, lohnt es sich, mehr Aufwand in das Erzeugen der Daten und das Monitoring zu investieren, da hierdurch die Effizienz erheblich gesteigert werden kann (Smart Fuzzing). Mittlerweile gibt es eine gro\u00dfe Palette an verf\u00fcgbaren Fuzzing-Werkzeugen (https:\/\/github.com\/secfigo\/Awesome-Fuzzing#tools). Neben vielen spezialisierten Tools, wie z.B. Fuzzer f\u00fcr bestimmte Dateiformate oder Netzwerkprotokolle, existieren auch Frameworks, welche durch entsprechende Konfiguration vielseitig einsetzbar sind.<\/p>\n Durch Fuzzing gefundene Fehler sind in ihrer Natur oft schwerwiegend, wie z.B. Buffer Overflows, Integer Overflows, Denial of Service (DoS) oder Code Injection Schwachstellen (XSS, SQLi) [6]. Dar\u00fcber hinaus ist Fuzzing ein gut automatisierbares, kosteneffektives Testverfahren mit dem Potenzial, die bei Code Review, Unit Test und Co. nicht entdeckten Fehler zu detektieren (extreme oder nicht sinnvolle Eingaben). Beachtet werden muss, dass das Ausf\u00fchren von Millionen von Testf\u00e4llen mitunter sehr zeitaufwendig sein kann und daher eine gute Planung und Integration in den Entwicklungsprozess erfordert. Wie bei allen Testmethoden kann auch der Fuzzing-Test kein komplettes Bild vorhandener Schwachstellen wiedergeben, und eine Software ohne Fehler beim Fuzzing ist damit nicht automatisch sicher.<\/p>\n F\u00fcr Software auf Steuerger\u00e4ten gelten oft andere Rahmenbedingungen, woraus sich neue Herausforderungen an das Fuzzing ergeben, haupts\u00e4chlich dadurch, dass Fuzzing-Tool und getestete Software auf getrennten Systemen laufen. Als Testdatenformat sind meist spezielle Nachrichtenprotokolle wie CAN, LIN oder ARINC einzuhalten, und die \u00dcbertragung an das Steuerger\u00e4t erfordert oft zus\u00e4tzliche Hardware und Software. Mit sogenannte Breakout-Boxen l\u00e4sst sich zudem eine Systemumgebung simulieren (Sensoren und Nachrichten-Bus). Beim Monitoring besteht die Schwierigkeit, Fehler bei der Ausf\u00fchrung auf dem Steuerger\u00e4t zu detektieren. JTAG-Debugger sind hier oft die einzige M\u00f6glichkeit, den internen Zustand zu beobachten. In einem Blackbox-Testszenario k\u00f6nnen Timeout-Kriterien eine praktikable L\u00f6sung darstellen, wobei ein vorhandener Watchdog deaktiviert werden sollte.<\/p>\n Getestet werden soll eine Softwarekomponente, welche auf der Anwendungsschicht CAN Nachrichten auf einem Steuerger\u00e4t verarbeitet. Eine CAN-Nachricht besteht vereinfacht aus einer ID, der Angabe zur Nachrichtenl\u00e4nge und dem Nachrichteninhalt. Nicht protokollkonforme Nachrichten w\u00fcrden bereits bei der \u00dcbertragung \u00fcber die CAN-Hardware blockiert, und bei Nachrichten mit ung\u00fcltiger ID w\u00fcrden diese nicht an die entsprechende Softwarekomponente \u00fcbergeben. Spezielle Login- und Logoff-Nachrichten m\u00fcssen zu Beginn und Ende einer Verbindung gesendet werden, und auf jede gesendete Nachricht folgt eine Antwortnachricht vom Steuerger\u00e4t.<\/p>\n F\u00fcr das Fuzzing eines solchen Systems m\u00fcssen die Voraussetzungen zum Senden und Empfangen auf den CAN-Bus geschaffen werden. Die notwendige Hardware und Treiber m\u00fcssen installiert und eine Anbindung des Fuzzing-Programms an die Treiber-API hergestellt werden. Die Erzeugung der Testdaten sollte Login und Logoff ber\u00fccksichtigen und vorwiegend den Datenbereich und die L\u00e4ngenangabe fuzzen. Dies steigert die Effizienz des Fuzzing und somit auch die Chance, Fehler zu detektieren. Trotz der benutzerdefinierten Gegebenheiten ist es oft nicht notwendig, ein spezialisiertes Fuzzing-Programm zu entwickeln, da es Fuzzing-Frameworks gibt, welche sich entsprechend konfigurieren lassen. F\u00fcr das Monitoring ergeben sich mehrere M\u00f6glichkeiten. Z.B. kann bereits das Ausbleiben einer Antwortnachricht vom Steuerger\u00e4t zur Fehlerdetektion genutzt werden (Timeout-Kriterium). Durch Verwendung eines JTAG-Debuggers l\u00e4sst sich z.B. der Stacktrace bei auftretenden Fehlern ermitteln.<\/p>\n Fuzzing ist eine ernstzunehmende Testmethode und wird bereits erfolgreich bei Desktop- und Web-Applikationen eingesetzt. Im Kontext eingebetteter Systeme werden Fuzzing-Tests allerdings kaum eingesetzt, obwohl es gewisse \u00c4hnlichkeit zu herk\u00f6mmlichen Computernetzwerken gibt. Einzelne Steuergr\u00e4te sind \u00fcber verschiedene Netzwerktypen, wie CAN, LIN oder ARINC, miteinander verbunden; somit ist Fuzzing als Teil des Security-Testprozesses gut denkbar.<\/p>\n Da immer mehr eingebettete Systeme \u00fcber Komponenten mit „online“ Funktionalit\u00e4t verf\u00fcgen, lassen sich zudem die Erfahrungen aus Fuzzing-Tests klassischer Protokolle (TCP\/IP) und modernen Anwendungen (z.B. Web- und Smartphone-Apps) nutzen. Security-Testmethoden wie Fuzzing k\u00f6nnten sich zuk\u00fcnftig auch in Safety-Standards wie der ISO 26262 wiederfinden, um den aktuellen Stand der Technik an die Sicherheitsanforderungen zu erf\u00fcllen [7].<\/p>\n [1] C. Miller and C. Valasek, „Adventures in Automotive Networks and Control Units,“ DEFCON 21 Hacking Conference, 2013.<\/p>\n [2]\u00a0„Car Hacking Research: Remote Attack Tesla Motors“, Keen Security Lab<\/a><\/p>\n [3]\u00a0„Los, Hacker, brecht mir das Herz!: Sicherheit von vernetzter Medizintechnik auf dem Pr\u00fcfstand“<\/a><\/p>\n [4]\u00a0„Schadsoftware im Atomkraftwerk Gundremmingen“, heise.de News<\/a><\/p>\n [5]\u00a0„92 Percent of Internet-Available ICS Hosts Have Vulnerabilities“<\/a><\/p>\n [6]\u00a0Prasanna Padmarajulu, „Discovering vulnerabilities with Fuzzing“, PenTest Magazin 04\/2017<\/a><\/p>\n [7] Bayer S., Enderle T., Oka DK., Wolf M. (2016) Automotive Security Testing – The Digital Crash Test. In: Langheim J. (eds) Energy Consumption and Autonomous Driving. Lecture Notes in Mobility. Springer<\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema\u00a0Qualit\u00e4t, Safety & Security<\/strong>.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Qualit\u00e4t, Safety & Security steht\u00a0hier\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\n
\n<\/strong><\/p>\nBeitrag – Embedded Software Engineering Kongress 2017<\/h3>\n
Sichere Software-Entwicklung: Ziel und Standpunkt von Software-Test<\/h2>\n
Fuzzing-Tests<\/h2>\n
Daten generieren<\/h3>\n
Daten bereitstellen<\/h3>\n
Monitoring<\/h3>\n
Fuzzing von eingebetteten Systemen<\/h2>\n
Beispiel CAN-Nachrichten-Fuzzing<\/h2>\n
Zusammenfassung<\/h2>\n
Literatur<\/h2>\n
\nUnsere Trainings & Coachings<\/h2>\n
\nQualit\u00e4t, Safety & Security – Fachwissen<\/h2>\n