FAKULTÄT INFORMATIK
Bachelorarbeit
Umsetzung von automatisierten Vulnerability Tests von Embedded Devices
Konrad Kreitmair
Betreuer: Prof. Dr.-Ing. Johann Uhrmann
Erklärung zur Bachelorarbeit
Kreitmair Konrad
Hochschule Landshut Fakultät Informatik
Hiermit erkläre ich, dass ich die Arbeit selbständig verfasst, noch nicht anderweitig für Prüfungszwecke vorgelegt, keine anderen als die angegebenen Quellen oder Hilfsmittel benutzt, sowie wörtliche und sinngemäße Zitate als solche gekennzeichnet habe.
...... (Datum) (Unterschrift des Studierenden)
Abstract
Ziel der Bachelorarbeit war es, die Umsetzbarkeit von automatisierten Vulnerability Tests von Embedded Devices zu prüfen. Eine solche Umsetzbarkeit wurde an den Virtu- al Private Network (VPN) Routern der Aktien Gesellschaft (AG) Transfer Data Test (TDT) geprüft. Die VPN Router dienten dazu, bereits existierende Werkzeuge, die eine automatisierte Überprüfung auf Vulnerabilities ermöglichen, auf deren Verwendbarkeit zu prüfen. Diese Werkzeuge fordern jedoch eine Bereitstellung von mehreren Testgerä- ten, um alle Gerätevarianten zu überprüfen. Ebenfalls konnte deren Korrektheit weder bewiesen noch widerlegt werden. Deshalb wurde ein alternatives System entworfen, das maximal 2 Testgeräte für eine Überprüfung benötigt und zuverlässige Ergebnisse liefert. Das Ergebnis ist ein Gesamtsystem, dass einzelne Module enthält, die die Embedded Devices auf Vulnerabilities testen. Das Konzept hinter dem System ist generisch und modular gehalten, sodass dies auch auf verschiedene industrielle Anwendungen in an- deren Unternehmen anwendbar ist. Inhaltsverzeichnis
Inhaltsverzeichnis
Erklärung zur Bachelorarbeit ...... iii Abstract ...... v
1 Einleitung 1 1.1 Problemstellung und Zielsetzung ...... 1 1.2 Methodik und Aufbau ...... 2
2 Theoretische Grundlagen 4 2.1 Embedded Devices ...... 4 2.2 Vulnerability ...... 5 2.2.1 Common Vulnerabilities and Exposures ...... 6 2.2.2 Common Weakness Enumeration ...... 9 2.2.3 Common Platform Enumeration ...... 10 2.2.4 Common Vulnerability Scoring System ...... 11 2.3 Penetration Tests ...... 13 2.3.1 Phasen eines Penetrations Tests ...... 14 2.3.2 Ansätze für Penetration Tests ...... 16
3 Umsetzung von automatisierten Vulnerability Tests 19 3.1 Analyse der Geräte ...... 19 3.1.1 Betriebssystem ...... 21 3.1.2 Bestimmung der Angriffsoberfläche ...... 23 3.1.3 Festlegung der zu prüfenden Bereiche ...... 24 3.2 Festlegung der Vorgehensweise ...... 25 3.2.1 Prüfung der Pakete ...... 26 3.2.2 Prüfung der Web-Benutzerschnittstelle ...... 27 3.2.3 Prüfung von Verschlüsselungsalgorithmen ...... 28 3.3 Prüfung von existierenden Tools ...... 29 3.3.1 OpenVas und Nessus ...... 29 3.4 Anforderungen an die Architektur des Systems ...... 33 3.4.1 Automatisierbarkeit ...... 33 3.4.2 Modularität ...... 34 3.4.3 Schnittstellen zur Kommunikation ...... 35 3.4.4 Konfigurierbarkeit ...... 36 3.5 Umsetzung der Anforderungen ...... 36 3.5.1 Buildbot als Grundlage ...... 37
vi Inhaltsverzeichnis
3.5.2 Scanner Tools ...... 40 3.5.3 Zusammenführen der Tools ...... 52
4 Fazit 61
Literatur 63
Abbildungsverzeichnis 65
Quelltextverzeichnis 66
Glossar 67
Akronyme 68
vii 1 Einleitung
1 Einleitung
1.1 Problemstellung und Zielsetzung
Die TDT AG ist ein mittelständisches Unternehmen mit Firmensitz in Essenbach bei Landshut. TDT entwickelt und produziert seit über 30 Jahren Kommuni- kationskomponenten. Das Unternehmen TDT AG hat sich auf den Entwurf von Software- und Hardwareprodukten im Bereich Datenkommunikation spezialisiert. Die Produkte reichen von VPN oder Long Term Evolution (LTE) Router über maßgeschneiderte Lösungen bis hin zum Netzmanagementsystem.
Die Geräte ermöglichen den verschlüsselten Austausch von Daten und somit das sichere Einbinden von verteilten Netzwerken in ein Firmennetzwerk. Die Router bilden somit einen wichtigen Knotenpunkt in der Netzwerkstruktur der Kunden. Dadurch sind die installierten Geräte Bestandteil einer kritischen Infrastruktur. Die Abbildung 1.1 zeigt ein Beispielkonzept, wie die einzelnen VPN-Router oder Dienstleistungen verwendet werden können.
Um diese Produkte gefahrlos in das Netzwerk zu integrieren, müssen diese Ge- räte mindestens den aktuellen Sicherheitsanforderungen entsprechen. Leitlinien für solche Anforderungen werden beispielsweise vom Bundesamt für Sicherheit in der Informationstechnik (BSI) veröffentlicht. Da sich diese im Verlaufe der Zeit ändern, müssen diese ständig angepasst und überprüft werden. Das Einhalten der Sicherheitsanforderungen bildet somit einen wichtigen Qualitätsfaktor der Router.
Solch eine Überprüfung muss entwicklungsbegleitend geschehen, um Sicherheits- lücken, die während der Entwicklung entstehen, sofort erkennen zu können. Um dies zu gewährleisten, müssen die Geräte ständig überprüft werden, was wieder- um einen hohen Grad an Automatisierung erfordert. Bei Embedded Devices ist hier die Herausforderung, dass diese als ganze Einheit getestet werden müssen. Sie bestehen oft aus einer großen Anzahl von Applikationen, die auf den Systemen zusammenwirken. Durch den höheren Automatisierungsgrad können Kosten für die Durchführung der Tests und deren Entwicklung niedrig gehalten werden.
Ziel der Bachelorarbeit ist es, ein System zu entwickeln, dass während der Ent- wicklung der Router automatisiert bekannte Vulnerabilities in diesen identifiziert. Erkannte Vulnerabilities können somit vor Auslieferung der Geräte verifiziert, ana- lysiert und behoben werden, sodass nur Produkte ausgeliefert werden, die auch
1 1 Einleitung
Abb. 1.1: Beispielkonzept, das eine mögliche Verwendung der Geräte und Dienstleis- tungen zeigt. Quelle: [15] sicherheitstechnisch eine hohe Qualität aufweisen. Das Grundkonzept des System soll jedoch so generisch gehalten sein, dass es auch auf andere Embeded Devices angewendet werden kann.
1.2 Methodik und Aufbau
Bevor eine Umsetzung erfolgen kann, werden im Kapitel 2 alle theoretischen Grundlagen geschaffen. Im einzelnen werden hier die Begriffe Embedded Devices, Vulnerabilities und Penetration Tests erklärt.
In Kapitel 3 erfolgt die eigenltiche Umsetzung der automatisierten Vulnerabi- lity Tests. Dabei werden in Kapitel 3.1 die Geräte analysiert, danach erfolgt die Festlegung der Vorgehensweise in Kapitel 3.2. Daraufhin werden in Kapitel 3.3 existierende Werkzeuge überprüft. Um danach ein alternatives Gesamtsystem zu entwerfen, werden in Kapitel 3.4 Anforderungen an die Architektur des Systems definiert. Liegen diese fest, wird in Kapitel 3.5 die Umsetzung der Anforderungen
2 1 Einleitung verfolgt.
In Kapitel 4 werden dann die wichtigsten Beobachtungen zusammengefasst und ein Fazit darüber gezogen. Abschließend wird ein Ausblick gegeben über die Er- weiterbarkeit und weiteren Einsatzmöglichkeiten.
3 2 Theoretische Grundlagen
2 Theoretische Grundlagen
In diesem Kapitel werden die Grundlagen für die Themen Embedded Devices, Vul- nerabilities und Penetrationstests erarbeitet. Dieses Kapitel soll zusätzlich Auf- schluss darüber geben, welche Teile dieser Gebiete für die Umsetzung der Arbeit notwendig sind, und was bei der Benutzung dieser zu beachten ist.
2.1 Embedded Devices
“Eingebettete Systeme (Embedded Devices) sind informationsbearbeitende Sys- teme, die in ein größeres Produkt integriert sind, und die normalerweise nicht direkt vom Benutzer wahrgenommen werden. Beispiele für eingebettete Systeme sind informationsverarbeitende Systeme in Telekommunikationsgeräten, in Trans- portsystemen wie Autos, Zügen, Flugzeugen, in Fabriksteuerungen und in Unter- haltungsgeräten.”[9, S. 1f]
Embedded Devices bestehen aus Hardware und Softwarekomponenten. Die Hard- ware ist meist speziell auf den Anwendungsfall angepasst, um Ressourcen wie Speicherplatz, Rechenleistung oder Energie effizient zu nutzen und dadurch die Herstellungskosten und Betriebskosten gering zu halten. Somit ist das Verwen- dungsgebiet des Gerätes meist auf eine Aufgabe beschränkt.
Die Softwarekomponenten definieren die Funktionalität des Systems. Die dar- auf verwendete Software muss je nach Verwendungszweck des Gerätes bestimmte Anforderungen erfüllen. Zum Beispiel muss das Steuersystem eines Autos in ei- ner definierten Zeitspanne ein korrektes Ergebnis liefern um beispielsweise den Bremsvorgang zu starten. Solch eine Anforderung wird Echtzeitanforderung ge- nannt. Dabei kann die verwendete Software selbst für die Steuerung des Systems zuständig sein, oder Teil eines Betriebssystems sein.
Die Router der TDT AG fallen unter die Kategorie Embedded Devices. Ihre Hardware ist für den Anwendungsfall Netzwerkkommunikation ausgerichtet. So- bald sie in ein Netzwerk eingebunden sind, interagiert ein Nutzer mit dem Gerät nur indirekt, indem er über das bereitgestellte Netz Daten sendet oder empfängt. Der Nutzer kann lediglich ein Fehlverhalten des Routers wahrnehmen, wenn bei diesem beispielsweise eine Ausnutzung einer Vulnerability stattfand, die jegliche Kommunikation stört. Vulnerabilities werden im folgenden Abschnitt genauer er-
4 2 Theoretische Grundlagen läutert.
2.2 Vulnerability
Der englische Begriff Vulnerability wird im Bereich der Informatik als Verwund- barkeit übersetzt. Als Vulnerability wird eine Schwachstelle eines Systems bezeich- net, unabhängig ob Software- oder Hardwaresystem, durch deren Ausnutzung Ak- tionen durchgeführt oder Ereignisse ausgelöst werden können, die sicherheitskri- tisch für das System oder dessen Umgebung sind. Welche Aspekte der Sicherheit dies betrifft, hängt vom System ab. [5, S. 16]
Als Beispiel für ein System mit Vulnerabilities kann ein Haus dienen. Sicher- heitskritisch ist hier, dass sich unbefugte Zugang zum Haus verschaffen können, obwohl alles verschlossen ist. Ein Eindringen in das Haus kann durch eine Türe, durch ein Fenster, durch das Dach oder durch eine Mauer erfolgen. Diese vier Elemente sind somit jeweils Schwachstellen des Systems. Diese werden zu Vul- nerabilities, wenn sie durch eine Bedrohung ausgenutzt werden können. In Bezug auf das Haus liegt die Bedrohung darin, das das Sicherheitsziel, das kein Unbe- fugter sich Zugang verschaffen kann, durch ein Ereignis gefährdet wird. Wird die Bedrohung realisiert, wenn beispielsweise der Einbrecher durch das Zerstören ei- nes Fensters in das Haus eindringt, nennt man dies einen Angriff.
Schwachstellen besitzen Eingenschaften wie, welche Auswirkungen hat eine Aus- nutzung, wie einfach ist diese auszunutzen oder ob es eine Möglichkeit gibt, diese Vulnerability zu schließen. Es existieren viele solcher Eigenschaften, wobei die wichtigsten noch im Verlauf dieser Arbeit genauer beschrieben werden.
Gründe für Schwachstellen in Systemen reichen von konfigurationsbedingten Schwä- chen, über Fehler bei der Implementierung bis hin zu Fehlern im Design. Hier spielen Faktoren wie eine hohe Komplexität des Systems, oder eine marktgedrun- gene kurze Entwicklungszeit eine wesentliche Rolle.
Am Beispiel des Hauses wurden Vulnerabilities gefunden. Diese wurden durch eine genauere Analyse/Test des Hauses aufgedeckt. Solche Tests werden im all- gemeinen Penetrationstests genannt. Die Vorgehensweise solcher Tests wird im Teil 2.3 genauer vorgestellt.
Ein Penetrationstest eines Systems kann von jedem durchgeführt werden, der Zugang oder Wissen über das System hat. Findet dieser Tester eine Vulnerability, kann er diese geheim halten, einer Gruppe mitteilen oder allgemein veröffentli- chen. Somit kann eine Vulnerability folgende Bekanntheitsgrade erreichen: • keinem bekannt (diese wurden noch nicht entdeckt),
5 2 Theoretische Grundlagen
• nur dem Finder bekannt, wobei hier der Finder der Hersteller oder eine dritte Person sein kann, • nur einer Gruppe bekannt oder • offiziell veröffentlicht. Für das offizielle Melden von Vulnerabilities existieren Anlaufstellen auf staatli- cher Seite. Solch eine Stelle ist notwendig, um redundante Auflistungen zu vermei- den und die Findbarkeit zu erhöhen. Zur Verwaltung dieser Informationen bietet sich eine Datenbank an.
Eine der bekanntesten Anlaufpunkte ist beispielsweise die National Vulnerabi- lity Database (NVD). Diese wurde im Auftrag der US-Regierung erstellt, um automatisiertes Schwachstellenmanagement durch standardisierte Daten zu er- möglichen. Die standardisierten Daten stammen von eingebunden Unterverzeich- nisse, die Vulnerabilities mit einer Identifikationsnummer versehen und nach wei- teren verschiedenen Metriken bewerten. Beispiele für diese Metriken sind die Art der Vulnerability, der Schweregrad, die zugrundeliegende Plattform oder die Schwierigkeit den Angriff durchzuführen. Ein Teil dieser Eigenschaften der NVD werden im Folgenden noch genauer erklärt. Die Datenbank ist zu finden unter https://nvd.nist.gov/vuln/search.
2.2.1 Common Vulnerabilities and Exposures Eine Common Vulnerabilities and Exposures (CVE) ist eine Verzeichnis von öf- fentlich bekannten Informations-Technologie (IT) Schwachstellen, die Informatio- nen zu ihnen enthalten. Dieses wurde in Zusammenarbeit von der MITRE Orga- nisation und dem National Institute of Standards and Technology (NIST) erstellt. Dieses Verzeichnis wird auch in der NVD verwendet [11].
Unter einem CVE versteht man einen CVE-Eintrag. Dieser wird mit einer Iden- tifikationsnummer, eine Beschreibung und mindestens einer öffentlichen Referenz versehen. Die minimale Datenstruktur wird durch eine Beschreibung mithilfe eines Schema definiert [4]. { "data_type": "CVE", "data_format": "MITRE", "data_version": "4.0", "CVE_data_meta": { "ID":"CVE-YYYY-NNNNNN", "ASSIGNER": "Example email address" }, "affects": { "vendor": { "vendor_data": [
6 2 Theoretische Grundlagen
{ "vendor_name": "Example corp.", "product": { "product_data": [ { "product_name": "Example product", "version": { "version_data": [ { "version_value": "1.0" } ] } } ] } } ] } }, "problemtype":{ "problemtype_data":[ { "description":[ { "lang": "string ISO 639-2", "value":"string description of problem_type" } ] } ] }, "references":{ "reference_data":[ { "url":"string for url location" } ] }, "description":{ "description_data":[ { "lang": "string ISO 639-2", "value":"string description of vulnerability" } ] } } Quelltext 2.1: JSON-Schema zur Definition eines CVE Eintrags
Die wichtigsten Sektionen für die Bachelorarbeit sind die
7 2 Theoretische Grundlagen
• CVE Identity (ID), • das Produkt (product), • die Version (version) und • die Schwächenart (problemtype). Die CVE-ID, enthält drei Teile, die durch einen Bindestrich getrennt sind. Diese sind die: • CVE als Identifizierung als CVE ID zur Unterscheidung von anderen Listen • Das Jahr der Entdeckung • Die fortlaufende Nummer für das Jahr Abbildung 2.1 soll dies nochmal verdeutlichen. Die ID ist wichtig, damit die Vul-
Abb. 2.1: Komponenten einer CVE-ID nerability eindeutig zuordenbar ist. Dies ist hilfreich, wenn eine Warnung heraus- gegeben wird oder die Schwachstelle durch mehrere Personen analysiert wird.
Unter der Produkt Sektion werden Produkte angegeben, die von der Schwachstel- le betroffen sind. Diese werden oft in der Common Platform Enumeration (CPE) Struktur angegeben, die im Abschnitt 2.2.3 genauer beschrieben wird. Dies ermög- licht eine Suche nach allen bekannten Schwachstellen für ein bestimmtes Produkt.
Die Version verweist auf die Hard- oder Softwareversion des Produkts. Dies ist hilfreich, um die Menge der betroffenen Produkte einzugrenzen.
Die Schwächenart gibt an um welche Art von Schwachstelle es sich handelt und wird als Common Weakness Enumeration (CWE) Datenstruktur angegeben.
8 2 Theoretische Grundlagen
Diese wird im Abschnitt 2.2.2 dargestellt.
Durch dieses Verzeichnis, können gefundene Schwachstellen veröffentlicht und ge- sucht werden. Der Zusammenschluss der aufgelisteten Sektionen beschreiben die Schwachstellen sehr genau. Das Verzeichnis wird weltweit verwendet, sodass hier auch der größte Datensatz über bekannte Schwachstellen enthalten ist. Ebenfalls wird durch das Festlegen der genannten Datenstruktur eine maschinelle Verarbei- tung möglich. Dadurch wird eine Verwendung dieses Verzeichnisses in der Bachel- orarbeit angestrebt. Es existieren neben der NVD noch viele weitere Datenbanken, die dieses Verzeichnis um weitere Informationen erweitern. Ein Beispiel für solch ein Projekt ist die cve-search Datenbank die im späteren Verlauf noch genauer beschrieben wird.
Wie bereits aufgezeigt, kann für eine Schwachstelle festgestellt werden, um wel- che Art es sich handelt. Die Handhabung dieser wird im folgendem Abschnitt dargestellt.
2.2.2 Common Weakness Enumeration CWE ist eine von der Gemeinschaft entwickelte Liste von gemeinsamen Schwä- chen der Software-Sicherheit. Es dient als gemeinsame Sprache, als Messlatte für Software-Sicherheitstools und als Grundlage für die Identifizierung von Schwach- stellen, deren Beseitigung und Prävention [10].
Ein CWE-Eintrag, kurz CWE genannt, enthält Informationen wie zum Beispiel folgende: • CWE Identifikationsnummer/Name des Schwächen Typs • Beschreibung des Typs • Alternative Bedingungen für die Schwäche • Beschreibung des Verhaltens der Schwäche • Beschreibung der Ausnutzung der Schwäche • Wahrscheinlichkeit der Ausnutzung der Schwäche • Beschreibung der Folgen des Missbrauchs • Mögliche Eindämmungen • Programm Beispiele für die Sprachen/Architekturen
9 2 Theoretische Grundlagen
• CVE IDs der Schwachstellen, für die diese Art von Schwäche besteht • Referenzen Durch solch einen Eintrag werden Schwächen innerhalb von Software kategori- siert, die zu einer Vulnerability in einem System führen können. Im Bezug auf eine gefundene Schwachstelle liefern diese Informationen einen ersten guten An- haltspunkt, um die Vulnerability genauer zu analysieren, zu verifizieren und zu beheben.
Sie werden von der MITRE Organisation im Verzeichnis CVE List verwaltet, welches wiederum ebenfalls in die NVD eingebunden ist.
2.2.3 Common Platform Enumeration Wie bereits im Abschnitt 2.2.1 dargestellt wurde, werden zu jeder Schwachstelle die betroffenen Versionen und Produkte, auch Plattformen genannt, angegeben. Die NIST erstellte eine Datenstruktur, die es erlaubt Plattformen eindeutig iden- tifizierbar zu machen. Sie basieren auf der generischen Syntax für Uniform Re- source Identifiers (URI) und somit beinhalten CPEs ein formales Namensformat, ein Verfahren zum Überprüfen von Namen gegen ein System und ein Beschrei- bungsformat zum Binden von Text und Tests an einen Namen [12].
Der gesamte Aufbau einer solchen URI in der Version 2.3 ist wie folgt: cpe:2.3:part:vendor:product:version:update:edition:language:sw_edition :target_sw:target_hw:other Der Aufbau erlaubt es auch, Teile unspezifiziert zu lassen. Dies soll folgendes Beispiel einer CPE zeigen. Alle für die Arbeit wichtigen Teile werden anhand dieses Beispiels darauf folgend genauer erklärt. cpe:2.3:a:microsoft:internet_explorer:8\.*:sp?:*:*:*:*:*:* Als part ist eine Applikation definiert. Der vendor (Anbieter/Hersteller) ist Mi- crosoft. Das Produkt ist der Internet Explorer (internet explorer). Es betrifft alle Versionen die eine 8. als Präfix haben. Als Update sind im Beispiel alle Service Packs definiert. Das Fragezeichen steht hier für ein regulären Ausdruck Token, der als Platzhalter für kein oder genau ein Zeichen steht. Der * ist hier ebenfalls ein solcher Token, der als Platzhalter für kein oder mehrere Zeichen steht. Somit ergibt sich, dass alle hinteren Attribute nicht spezifiziert sind.
Laut Spezifikation kann für das part Attribut einer der Werte, ”a” für Appli- kation, ”o” für Betriebssystem oder ”h” für Hardwaregerät gewählt werden [13].
10 2 Theoretische Grundlagen
Ein wesentlicher Bestandteil des CVE-Analyseprozesses ist die eindeutige Identi- fizierung der gefährdeten Produkte, die von einer bestimmten Schwachstelle be- troffen sind. Dafür können die CPE Einträge in einem CVE genutzt werden. Um- gekehrt kann somit nach allen Schwachstellen eines Produktes gesucht werden. Eine solche Kombination von Common Vulnerabilities Exposures und Common Platform Enumeration wird in dieser Bachelorarbeit genutzt.
2.2.4 Common Vulnerability Scoring System Das Common Vulnerability Scoring System (CVSS) System bietet einen offe- nen Rahmen für die Kommunikation der Merkmale und Auswirkungen von IT- Schwachstellen. Sein quantitatives Modell gewährleistet eine wiederholgenaue Mes- sung und ermöglicht es den Benutzern, die zugrunde liegenden Schwachstellen- merkmale zu sehen, die zur Generierung der Ergebnisse verwendet wurden. CVSS eignet sich daher gut als Standardmesssystem für Branchen, Organisationen und Regierungen, die genaue und konsistente Schwachstellenauswirkungswerte benö- tigen. Zwei häufige Anwendungen von CVSS sind die Priorisierung von Aktivi- täten zur Behebung von Schwachstellen und die Berechnung des Schweregrads von Schwachstellen, die auf den eigenen Systemen entdeckt wurden. Die Natio- nal Vulnerability Database (NVD) liefert CVSS-Scores für fast alle bekannten Schwachstellen [14].
Das CVSS ermöglicht eine Berechnung abhängig von Eigenschaften der Schwach- stelle. Diese liefert eine Punkteanzahl im Intervall von 0 bis 10. Die Punktanzahl, im weiteren auch Score genannt, wird dann für die drei Metriken Base Score, Temporal Score und Environmental Score verwendet. Diese Metriken werden im weiteren Verlauf genauer dargestellt.
Je nach Punkteanzahl des Base Scores kann die Schwachstelle dann einem Schwe- regrad zugeordnet werden, der von der Version des CVSS abhängig ist. Mittler- weile ist das CVSS in der Version 3 (CVSSv3) vorhanden. Die Vorgängerversion (CVSSv2) ist jedoch noch weiter im Gebrauch. Die Zuordnung der Punkte zum einzelnen Schweregrad kann folgender Abbildung 2.2 entnommen werden. An- zumerken ist, dass beim Versionswechsel auch Änderungen am Algorithmus zur Berechnung der Punktezahl vorgenommen wurden. Diese sind nicht direkt ver- gleichbar, da die neuere Version mehrere Parameter berücksichtigt. Um eventuelle Fehler zu vermeiden, werden bei einer großen Anzahl von CVEs in der NVD beide Punkttanzahlen gespeichert.
Für die Darstellung der einzelnen Metriken die zur Berechnung der Scores ver- wendet werden, wird das CVSS in der Version 3 verwendet.
11 2 Theoretische Grundlagen
Abb. 2.2: Kategorisierung des Schweregrads einer Schwachstelle je nach CVSS Version Quelle: [14]
Base Score Metric Die Gruppe Base Metric repräsentiert die intrinsischen Merkmale einer Schwach- stelle, die im Laufe der Zeit und in allen Benutzerumgebungen konstant sind. Es besteht aus zwei Sätzen von Metriken: den Ausnutzungsmetriken und den Wir- kungsmetriken [6].
In den Ausnutzungsmetriken sind wiederum Metriken enthalten. Diese Unter- metriken beschreiben, • den Angriffsvektor wie zum Beispiel Lokaler Zugriff oder über ein Netzwerk, • die Angriffskomplexität, • die Privilegien, die für die Schwachstellenausnutzung benötigt werden, • ob eine Benutzerinteraktion für die Ausnutzung erforderlich ist und • ob andere Ressourcen außerhalb der Privilegien der ausgenutzten Software beeinträchtigt werden können. In den Wirkungsmetriken sind ebenfalls weitere Untermetriken enthalten. Diese beschreiben, • die Auswirkungen auf die Vertraulichkeit eines Systems, • die Auswirkungen auf die Integrität und • Auswirkungen auf die Verfügbarkeit des Systems.
12 2 Theoretische Grundlagen
Der Base Score ist notwendig, um einen CVSS-Eintrag für eine Schwachstelle zu erhalten. Darum müssen Werte für alle diese Untermetriken zur Berechnung angegeben werden.
Temporal Score Metric Die Gruppe Temporale Metrik spiegelt die Merkmale einer Schwachstelle wieder, die sich im Laufe der Zeit ändern kann, aber nicht in allen Benutzerumgebungen. So würde beispielsweise das Vorhandensein eines einfach zu bedienenden Exploit- Kits den CVSS-Wert erhöhen, während die Erstellung eines offiziellen Patches ihn verringern würde [6].
Environmental Score Metric Diese Kennzahlen ermöglichen es dem Analysten, den CVSS-Score je nach der Bedeutung des betroffenen IT-Systems für das Unternehmen eines Benutzers an- zupassen, gemessen an ergänzenden/alternativen Sicherheitskontrollen, Vertrau- lichkeit, Integrität und Verfügbarkeit. Die Metriken sind das modifizierte Äquiva- lent der Basismetriken und erhalten einen Metrikenwert, der auf der Platzierung der Komponenten in der Unternehmensinfrastruktur basiert[6].
Wird also eine Vulnerability entdeckt, zu der ein CVSS angegeben ist, ermöglicht dies eine schnelle Entscheidungsfindung bezüglich der Priorisierung der Analyse oder Behebung der Vulnerability.
2.3 Penetration Tests
Die Umsetzung der Bachelorarbeit erfordert eine genaue Analyse des Systems auf Angreifbarkeit. Solche Analysen bilden die Grundlage im Bereich Security Engi- neering und sind dort unter Penetration Tests bekannt.
Ein Penetration Test ist ein Verfahren, das unter vorgegebenen Bedingungen die Vorgehensweise zur Analyse eines Systems bezüglich Angreifbarkeit definiert. Un- ter Bedingungen versteht man die Art des Ansatzes und die Menge der Informatio- nen über das System um dieses detaillierter zu betrachten. Diese Ansätze werden im Abschnitt 2.3.2 aufgezeigt.
Einige Firmen haben sich auf die Durchführung von Penetrations Tests spe- zialisiert. In manche Unternehmen existieren Abteilungen, die solche Analysen ausführen. Diese Organisationen werden beauftragt, Systeme, Dienste oder den Zusammenschluss solcher auf Vulnerabilities zu prüfen.
13 2 Theoretische Grundlagen
Die Vorgehensweise für die Durchführung eines Penetrationstests kann in einzel- ne Phasen aufgeteilt werden, die im folgenden Abschnitt 2.3.1 genauer betrachtet werden.
2.3.1 Phasen eines Penetrations Tests Das Ziel eines Penetrationstests ist es, Schwachstellen zu finden, diese auszunut- zen, und zu dokumentieren. Um die Befunde reproduzieren zu können, muss der Weg zu den Schlussfolgerungen nachvollziehbar sein. Dafür ist es notwendig eine geregelte Vorgehensweise festzulegen. Die Vorgehensweise bei der Durchführung ist meist nicht vom zu analysierenden System abhängig. Für das Durchführen von Penetrationstests haben sich mehrere Phasen herauskristallisiert. Für die Umset- zung von automatisierten Vulnerability Tests sind jedoch nur folgende Phasen relevant: • Informationen sammeln • Vulnerabilities identifizieren • Resultate dokumentieren • Daten archivieren
Informationen sammeln Die Informationsbeschaffung ist der erste Schritt zur Durchführung eines Pene- trationstests und wird als wohl wichtigster Schritt bezeichnet. Nach Abschluss dieser Phase sollte das System detailliert bekannt sein. Dazu gehören Informatio- nen über die verwendete Hardware, das Betriebssystem, sich darauf befindliche Anwendungen und alle Schnittstellen zum System. Ist dies bekannt, können Tools ausgewählt werden und die benötigte Infrastruktur für den Test festgelegt werden.
Das Sammeln der Informationen kann in die zwei Gebiete passives und aktives Sammeln aufgeteilt werden. Unter passiven sammeln versteht man das Beschaf- fen von Informationen über das System ohne sich mit ihm direkt zu verbinden. Dies können beispielsweise Informationen über der Hersteller und des Typs des Gerätes sein, die durch lesen der Beschriftungen auf dem Gerät ermittelt wurden. Die Informationen können dann durch tiefere Recherchen im Internet erweitert werden.
Bei aktiven Sammeln verbindet man sich direkt mit dem Gerät und versucht sich somit weitere Informationen zu beschaffen. Zum Beispiel können hier Infor- mationen gesammelt werden über die installierten Applikationen, die verwendete Konfiguration, oder die Schnittstellen des Systems.
14 2 Theoretische Grundlagen
Das Sammeln von Information stellt einen großen Aufwand dar. Ein Teil kann automatisiert geschehen, jedoch muss ein geringer Teil per Hand recherchiert wer- den. Der letztere Teil besitzt somit keinen hohen Automatisierungsgrad. Wurden diese jedoch einmal gesammelt, können auf Basis dieser automatisierte Tests im- plementiert werden. Um dies zu erreichen müssen die gesammelten Informationen für einen gewissen Zeitraum genutzt werden. Bei der entwicklungsbegleitenden Überprüfung wirft dies jedoch ein neues Problem auf.
Komponenten eines Systems können sich während der Entwicklung und Wartung ändern. Darum müssen die Informationen in Bereiche bezüglich ihrer Änderungs- häufigkeit aufgeteilt werden. Informationen, die sich kaum ändern, können über einen längeren Zeitraum verwendet werden. Informationen die sich häufig ändern, müssen bei jeder Überprüfung neu gesammelt werden. Wenn es jedoch eine Mög- lichkeit gibt, die automatisiert Informationen sammelt über die sich häufig än- dernden Komponenten, kann eine automatisierte Gesamtüberprüfung umgesetzt werden.
Um die gesammelten Informationen maschinell zu verwerten, müssen die Informa- tionen strukturiert gespeichert werden. Diese enthalten ebenso maschinell lesbare Datenstrukturen wie beispielsweise die CVE, CPE, CWE oder die CVSS zu einer Vulnerability.
Vulnerabilities identifizieren Nachdem alle relevanten Informationen, wie zum Beispiel die Liste der installier- ten Applikationen auf dem System, zusammengetragen wurden, können mithilfe einer Internetrecherche Vulnerabilities für diese gesucht werden. Für diese Re- cherche ist die NVD, wie bereits im Kapitel 2.2 erläutert, eine der qualitativ hochwertigsten und aktuellsten Quellen zur Identifizierung von Vulnerabilities. Es ist hier anzumerken, dass durch jenes Vorgehen nur bekannte/veröffentlichte Vulnerabilities gefunden werden können.
Für die Identifizierung der Vulnerablities muss eine automatisierte Lösung gefun- den werden. Wie bereits im Abschnitt 2.3.1 erläutert, liegen die dafür benötigten Informationen maschinell lesbar vor und können somit automatisiert konsolidiert werden. Diese werden dann verwendet, um eine automatisierte Recherche nach bekannten Vulnerabilities durchzuführen.
Eine Verifizierung der gefundenen Schwachstellen und das Suchen von unbekann- ten Schwachstellen soll im Zuge der Bachelorarbeit nicht betrachtet werden.
15 2 Theoretische Grundlagen
Resultate dokumentieren Ist die Analyse abgeschlossen, müssen die Resultate in einem Bericht dokumen- tiert werden. Dies soll ebenfalls automatisiert geschehen. Der Bericht beinhaltet alle wesentlichen Informationen der Analyse.
Wesentliche Informationen für identifizierte Vulnerabilities sind, die CVE-ID, die CWE, der CVSS und die zugehörige CPE. Für identifizierte Schwachstellen sind die CWE und der CVSS wesentlich. Im Bericht sollen auch Metadaten wie, wann wurde welches System mit welchen Softwarestand und welchen Tools getestet, festgehalten werden.
Der Struktur des Berichts soll eine maschinelle Verarbeitung ermöglichen. Für den menschlichen Leser, muss der Bericht so strukturiert sein, dass durch ein schnelles Lesen ersichtlich wird, was der Sicherheitszustand des Systems ist.
Die in den Berichten enthaltenen Daten ermöglichen unter Berücksichtigung wei- terer Parameter eine Priorisierung, welche der identifizierten Vulnerabilities als erstes verifiziert und behoben werden sollen. Weitere Parameter können beispiels- weise sein, der zeitliche Aufwand zur Beseitigung oder ob das dafür benötigte Wissen für das Beheben der Vulnerability vorhanden ist.
Daten archivieren Die einzelnen Berichte müssen archiviert werden, um eine lang-zeitige Nachvoll- ziehbarkeit der Analysen zu gewährleisten. Diese können später auch für das er- stellen von Statistiken herangezogen werden. Somit kann ermittelt werden, in welchen Zeiträumen eine Schwachstelle in der Regel behoben werden konnte oder wie sich die Gesamtanzahl der Vulnerabilities im Laufe des Analysezeitraums ent- wickelt hat.
2.3.2 Ansätze für Penetration Tests Ein System kann von verschiedenen Blickwinkel betrachtet werden. Dies kann eine Innensicht, Außensicht oder eine Mischform von beiden sein. Diese Blickwinkel werden als Arten von Penetrations Tests bezeichnet. Sie sind unter den englischen Begriffen Whitebox, Blackbox oder Graybox Test bekannt. Je nach Blickwinkel liegen dem Tester andere Informationen über das System vor.
Blackbox Tests Der Blackbox-Ansatz soll einen Außentäter simulieren. Hierbei kann davon aus- gegangen werden, dass der Angreifer nahezu nichts oder nur leicht zugängliche Informationen über ein System verfügt [5, S. 210].
16 2 Theoretische Grundlagen
Der Tester weiß beispielsweise nur, wo das System zu finden ist. Alle weitere Informationen muss der Tester sich selbst beschaffen. Dadurch wird der Aufwand für die Informationsbeschaffungsphase erheblich erhöht. Jedoch kann somit fest- gestellt werden, ob der Tester Informationen findet, die eigentlich nicht öffentlich zugänglich sein sollten.
Whitebox Tests Der Whitebox-Ansatz simuliert einen Innentäter. Das heißt man geht davon aus, dass der Angreifer detaillierte Kenntnisse über die interne Struktur der Anwen- dungen und Dienste verfügt [5, S. 210].
Hier ist der Aufwand für die Informationsbeschaffung ziemlich gering. Dieser An- satz kommt einem Angriff gleich, den der Entwickler des Systems selbst durch- führt.
Graybox Tests Der Graybox Ansatz ist die Mischform von Blackbox und Whitebox. Der Tester simuliert eine Angreifer, der mehr Informationen über das zu testende System hat als ein Außentäter, jedoch weniger als ein Innentäter. Dies ist die meist verbreitete Ansatz von Penetrations Tests.
Hier werden zum Beispiel schon der Quellcodes des Betriebssystems oder Benut- zerhandbücher über den zu testenden Dienst den Tester bereitgestellt, da diese im Regelfall öffentlich leicht zu finden sind.
Zusammenführung Die automatisierten Vulnerability Tests sollen entwicklungsbegleitend geschehen. Dies heißt auch, dass ein Penetrationstest mehrmals hintereinander an einem System ausgeführt wird. Um dies zu erreichen, müssen die gezeigten Phasen zy- klisch angeordnet werden. Die Abbildung 2.3 soll dies verdeutlichen. Wie bereits im Abschnitt 2.3.1 erläutert, können Teile der Informationsbeschaffungsphase nicht ständig erneut ausgeführt werden. Deshalb bilden die Informationen, de- ren Grundlage sich nur selten ändert die Basis des Testzykluses. Die restlichen benötigten Informationen müssen bei jeder Zyklussrunde neu beschafft werden. Während der Testzyklus beliebig oft ausgeführt werden kann, wird die Beschaf- fung der Basisinformationen nur dann wiederholt, wenn sich deren Grundlage ändert. Die Grundlage ändert sich, wenn beispielsweise neues Know-How in die Geräte eingebracht wird oder sich die Testgeräte selbst ändern.
17 2 Theoretische Grundlagen
Abb. 2.3: Zyklus des automatisierten Pentestings
18 3 Umsetzung von automatisierten Vulnerability Tests
3 Umsetzung von automatisierten Vulnerability Tests
In diesem Kapitel werden im Abschnitt 3.1 als erstes die Geräte analysiert. An- schließend erfolgt im Abschnitt 3.2 die Festlegung der Vorgehensweise. Sind diese festgelegt, werden im Abschnitt 3.3 bereits vorhandene Tools geprüft. Danach werden im Abschnitt 3.4 weitere Anforderungen an das Testsystem gestellt. An- schließend werden im Abschnitt 3.5 die Anforderungen umgesetzt.
Bevor eine Umsetzung von automatisierten Vulnerability Tests möglich ist, müs- sen die Geräte erst analysiert werden. Dies entspricht der Informationsbeschaf- fungsphase eines Penetrationstests die im Abschnitt 2.3.1 genauer erläutert wur- den. Hier werden Informationen gesammelt, die für jeden Test benötigt werden. Auf der Basis dieser Analyse kann dann festgelegt werden, welche Komponenten automatisiert auf Verwundbarkeiten überprüft werden sollen. Sind die Kompo- nenten festgelegt, müssen Vorgehensweisen ermittelt werden, wie bekannte Ver- wundbarkeiten identifiziert werden können. Liegt die Vorgehensweise fest, müssen Tools gesucht werden, die in Frage kommen eine Überprüfung der Komponenten durchzuführen. Danach erfolgt eine Analyse der Tools auf Automatisierbarkeit und Genauigkeit. Sind die Tools festgelegt, werden die automatisierten Vulnera- bility Tests mit diesen umgesetzt.
3.1 Analyse der Geräte
Die folgenden Abbildungen 3.1 und 3.2 zeigen die Vorder- und Rückseite eines VPN Gateways der Firma TDT AG.
An diesen sind jeweils Schnittstellen wie beispielsweise ein Slot für eine Subscri- ber Identity Module (SIM) Karte oder die Anschlüsse für eine Antenne zu sehen. Die Abbildung 3.3 zeigen die Platine eines Routers. Hier werden die einzelnen verbauten Microchips ersichtlich.
19 3 Umsetzung von automatisierten Vulnerability Tests
Abb. 3.1: Vorderseite eines G3000 VPN-Gateways.
Abb. 3.2: Rückseite eines G3000 VPN-Gateways.
Zu sehen sind jeweils nur die Hardwarekomponenten der Geräte. Embedded Devices beinhalten jedoch auch Softwarekomponenten.
Die Hardwarekomponenten werden im Laufe der Entwicklung festgelegt. Diese verändern sich dann nur noch selten. Die Softwarekomponenten hingegen ändern sich häufiger. In Betracht der Informationsbeschaffungsphase bedeutet dies, dass Informationen über die Hardwarekomponenten langlebiger sind als die der Soft- warekomponenten. Somit bilden die Hardwareinformationen die Basis der Tests. Die Softwareinformationen müssen hingegen ständig neu beschafft werden.
20 3 Umsetzung von automatisierten Vulnerability Tests
Abb. 3.3: Board eines VR2020 Routers.
Ein sehr wichtiges Element der Softwarekomponente ist das Betriebssystem, dass im folgenden Abschnitt genauer betrachtet wird.
3.1.1 Betriebssystem Auf Embedded Devices wird Software verwendet, die die Funktionalität des Ge- rätes definiert. Auf den Routern der TDT AG wird als Grundlage dieser Software das Betriebssystem OpenWrt verwendet, das hauptsächlich für Netzwerkgeräte entwickelt wird.
OpenWrt ist ein Betriebssystem-Projekt, das quelloffen entwickelt wird. Dieses wird von Entwicklern weltweit betreut. Die Entwickler beschreiben das Projekt wie folgt: ”Das OpenWrt-Projekt ist ein Linux-Betriebssystem, das auf Embed- ded Devices ausgerichtet ist. Anstatt zu versuchen, eine einzelne, stati- sche Firmware zu erstellen, bietet OpenWrt ein vollständig beschreib- bares Dateisystem mit Paketverwaltung. Dies befreit den Nutzer von der Anwendungsauswahl und -konfiguration des Herstellers und ermög- licht es, das Gerät durch die Verwendung von Paketen an jede Anforde- rung anzupassen. Für Entwickler ist OpenWrt das Framework, um eine Anwendung zu erstellen, ohne eine komplette Firmware um sie herum erstellen zu müssen; für den Benutzer bedeutet dies die Möglichkeit der vollständigen Anpassung, um das Gerät auf eine Weise zu nutzen, die nie vorgesehen war.” [8] Die Hauptaufgabe eines solchen Projektes ist es, Pakete zu erstellen und zu pfle-
21 3 Umsetzung von automatisierten Vulnerability Tests gen um daraus eine GNU/Linux Distribution zu erstellen. Ein Paket selbst ist ein komprimiertes Archiv. Dieses enthält Programme oder Skripte, benötigte Konfi- gurationsdateien und Informationen über das Paket. Ein Teil der Informationen beschreibt, wie das Paket in das Betriebssystem zu integrieren ist. Diese Pakete werden durch einen Paketmanager verwaltet, der Pakete herunterlädt, öffnet, in- stalliert oder de-installiert.
Das OpenWrt Betriebssystem wird also durch das Zusammenfügen von Pake- ten um den Linux-Kernel herum erstellt. Dafür wird jedes einzelne Paket separat kompiliert und in einem temporären Ordner gespeichert. Danach wird dieser kom- primiert und später als nur lesbare Speicherpartition in die Firmware integriert. Die Erstellung einer Firmware, eines Speicherabbildes, stellt den letzten Schritt im Bauprozess eines Betriebssystems dar. Dieses Speicherabbild, oft auch Image genannt, wird dann auf dem entsprechenden Router direkt in den Flashspeicher geladen. Somit ist das Betriebssystem auf dem Gerät verfügbar. Der Linux-Kernel wird ebenfalls wie ein Paket gehandhabt. Dieser wird je nach gewünschten Ziel- system, um den Voraussetzungen des verwendeten Bootloaders auf dem Gerät gerecht zu werden, anders in das Image integriert.[16]
Somit ist das Hauptrepository von OpenWrt, zu finden unter https://git.openwrt. org/, als eine große Baubeschreibung des Betriebssystems zu verstehen. Beschrie- ben werden die einzelnen Pakete durch Makefiles, die vom Programm Make für das Bauen des Betriebssystems verwendet werden.
Die zu betrachtenden Router sind für spezielle Anwendungsfälle konzipiert. So- mit können sie sich in den Bereichen Hardwarearchitektur, Speicherkapazität, Erweiterbarkeit durch zusätzliche Module oder darauf verfügbare Software unter- scheiden. Dies hat zur Folge, dass für jedes Gerät und dessen Anwendungsfall, ein spezielles Image gebaut werden muss. Diese werden im weiteren Verlauf Image- ausprägungen genannt.
Die TDT AG verwendet die Pakete von OpenWrt, führt eventuelle Änderungen an ihnen durch, oder fügt neue hinzu. Sind alle Änderungen vollzogen, werden die einzelnen Images gebaut. Dies geschieht automatisiert durch ein sogenanntes Buildsystem. Dieses legt die erstellten Images in speziellen Ordnerstrukturen ab.
Derzeit werden die Rechnerarchitekturen lantiq_xrx200, ar71xx_generic, x86_64 und x86_geode in den Routern verwendet. Diese werden auf den Verschiedenen Plattformen wie den VR2020_DRNO oder dem APU3_STROMBERG einge- setzt. Diese sind durch Hardwaremodule wie einem Wireless Local Area Network (Wlan) Modul oder Digital Subscriber Line (DSL) Modul erweiterbar. Je nach Zu- sammensetzung aus Plattform und Modulen werden dann spezielle Images gebaut.
22 3 Umsetzung von automatisierten Vulnerability Tests
Vereinzelt werden auch für Kunden spezifische Images erstellt. Die Abbildung 3.4 soll diese Imageausprägungen zu den einzelnen Architekturen und Plattformen verdeutlichen. Jedes Ende eines Zweiges stellt eine Imageausprägung dar. Die Ge-
Abb. 3.4: Darstellung aller Imagesausprägungen zu den einzelnen Architekturen und Plattformen. samtanzahl der Ausprägungen für die Firma TDT AG liegt derzeit (März 2019) bei 25. Diese Images müssen auf Vulnerabilities geprüft werden. Dafür muss als erstes ersichtlich werden, wo ein Angriff jeweils stattfinden kann. Dies wird im folgenden Abschnitt genauer erläutert.
3.1.2 Bestimmung der Angriffsoberfläche Eine Angriffsoberfläche umfasst alle verschiedenen Punkte eines Systems, durch die ein Angreifer in das System eindringen kann und durch die Daten heraus ge- schleust werden können.
Die Bestimmung der Angriffsoberfläche erfolgt durch eine stark abstrahierte An- sicht der zu betrachtenden Geräte. Die Router bestehen aus den Hauptkompo- nenten Hardware und Software.
Die Hardwarekomponente setzt sich zusammen aus der verwendeten Hauptplatine
23 3 Umsetzung von automatisierten Vulnerability Tests und an der angebundenen Elektronik, wie beispielsweise Chips, Netzwerkkarten oder Speicherkarten. Darunter fallen bekannte Bauteile wie zum Beispiel die zen- trale Recheneinheit, auch Central Processing Unit (CPU) genannt. Eine CPU ist ein Zusammenschluss von integrierten Schaltkreisen die eine Logik bilden. Diese Logik wird meist durch Software in der CPU, auch Microcode genannt, erweitert. Um Fehler während der Entwicklung des Microcodes besser beheben zu können, werden Debugschnittstellen genutzt, die einen direkten Zugang zum Microcode auf der CPU ermöglichen. Solche Schnittstellen werden nach Vollendung der Ent- wicklung de-aktiviert. Sind sie dies nicht, können diese von Angreifern verwen- det werden, um beispielsweise Daten durch Anlegen von Messgeräten auszulesen. Durch Hardwarekomponenten kann also in ein System eingedrungen und sensible Daten ausgelesen werden. Somit tragen sie zur Angriffsoberfläche bei.
Die Softwarekomponente setzt sich aus dem verwendeten Betriebssystem, allen darauf befindlichen Applikationen und der Software, die von den Hardwarekom- ponenten benötigte wird, meist Firmware oder Microcode genannt, zusammen. Darunter fallen zum Beispiel der Bootloader, eine Software, die das System initia- lisiert, Programme, die es ermöglichen, eine VPN Verbindung aufzubauen oder Applikationen, die es den Benutzer ermöglichen, das System zu konfigurieren. Softwarekomponenten können bezüglich ihrer Interaktionsweise in drei Kategori- en eingeteilt werden: • Eine Interaktion mit der Software ist nur auf dem System möglich, • die Interaktion mit der Software findet von außen statt, • eine Interaktion ist durch eine Mischform der ersten beiden möglich. Ein Beispiel für Programme die nur auf dem System ausgeführt werden können, sind Kommandozeilenprogramme. Ein Programm, das von außen aufgerufen wer- den kann, ist beispielsweise ein Webserver, der Daten automatisch verarbeiten, sobald diese an das Gerät gesendet werden. Da ein Angreifer sich sowohl außerhalb und innerhalb eines Systems befinden kann, zählen alle Softwarekomponenten auf einem Gerät zur Angriffsoberfläche.
3.1.3 Festlegung der zu prüfenden Bereiche Der Fokus der Bachelorarbeit liegt in der Automatisierung von Vulnerability Tests von Embedded Devices. Wie bereits im Abschnitt 3.1.2 angeführt, benötigt die Überprüfung von Hardwarekomponenten mehr manuelle Arbeit vom Tester. Ebenso ist die Angriffswahrscheinlichkeit nicht so hoch wie bei Softwarekompo- nenten, da sich der Angreifer erst Zugang zum System beschaffen muss. Dies stellt für den Angreifer ein erhöhtes Risiko entdeckt zu werden dar. Aus die- sen genannten Gründen und um die Breite des Themas einzuschränken, wird die
24 3 Umsetzung von automatisierten Vulnerability Tests
Überprüfung der Hardwarekomponenten im Zuge der Bachelorarbeit nicht weiter betrachtet. Die Entwicklung des Testsystems sieht jedoch eine spätere Integration der Hardwareüberprüfung vor. Somit fällt das Hauptaugenmerk auf alle Software- komponenten.
Die einzelnen Softwarekomponenten können je nach Anforderungen konfiguriert werden. Wie in Kapitel 2.2 gezeigt, kann eine Vulnerability ebenfalls durch ei- ne Fehlkonfiguration entstehen. OpenWrt bietet eine hohe Konfigurierbarkeit des Systems was den verschiedenen Kundenanforderungen entgegen kommt. Dadurch steigt jedoch die Menge der möglichen Konfigurationsarten des Systems extrem. Das Vermeiden von konfigurationsbedingten Schwachstellen wird durch einen so- genannten Härtungsprozess erreicht. In diesen Prozess wird zuerst ein System konfiguriert und anschließend auf dessen Sicherheit geprüft. Wenn das System konfigurationsbedingte Schwachstellen aufweist, wird die Konfiguration nachjus- tiert. Da dieser Prozess keine hohe Automatisierbarkeit aufweist und eine ideale Konfiguration von den Bedürfnissen des Kunden abhängt, wird die Analyse auf konfigurationsbedingte Schwachstellen ebenfalls ausgeschlossen.
Im Abschnitt 3.1.1 wurde ersichtlich, das OpenWrt aus Paketen zusammenge- setzt ist. Die einzelnen Pakete zusammen bilden alle Softwarekomponenten des Systems. Um das System gänzlich auf bekannte Vulnerabilities zu prüfen, ausge- nommen der oben ausgeschlossenen Bereiche, müssen somit alle Pakete daraufhin geprüft werden.
3.2 Festlegung der Vorgehensweise
Im diesem Abschnitt wird die Vorgehensweise festgelegt, wie die Softwarekompo- nente am besten auf Vulnerabilities überprüft werden kann. Um einen besseren Überblick über die Softwarekomponente zu bekommen, hilft eine Unterteilung in drei Bereiche.
Den ersten Bereich bilden die für den Bau von OpenWrt verwendeten Softwarepa- kete. Im Entwichlungsprozess werden diese nicht oder nur gering gegenüber dem veröffentlichten Stand von OpenWrt verändert. Dadurch kann über die offizielle CPE URI nach bekannten Vulnerabilities gesucht werden.
Den zweiten Bereich bildet die Web-Benutzerschnittstelle. Je nach dem welche Hardwaremodule, zum Beispiel ein Wlan Modul, in einem Gerät verbaut sind, unterscheiden sich die Auswahlmöglichkeiten der Oberflächen zueinander. Dies fordert somit eine gesonderte Überprüfung.
Die ersten beiden Bereiche bilden die gesamte Softwarekomponente ab, jedoch ver-
25 3 Umsetzung von automatisierten Vulnerability Tests wenden einige der Pakete Verschlüsselungsalgorithmen. Diese Algorithmen bilden den dritten Bereich, da sie eine große Rolle in der sicherheitstechnischen Betrach- tung der Geräte spielen. Hier kann es vorkommen, dass deren Verwendung nicht mehr empfohlen wird, da sie als unsicher gelten. Deswegen muss die Aktualität dieser regelmäßig überprüft werden.
Somit ergeben sich folgende Bereiche: • Prüfung der Pakete. • Prüfung der Web-Benutzerschnittstelle. • Überprüfung auf Aktualität der verwendeten Verschlüsselungsalgorithmen.
3.2.1 Prüfung der Pakete Um bekannte Vulnerabilities für ein bestimmtes Paket zu finden können bereits existierende Scanner verwendet werden. Eine Suche findet meist über den Namen des Paketes statt. Dies wirft aber Probleme bei der genauen Zuordnung auf, da in den entsprechenden Datenbanken, die eine CPE URI für die Suche von CVEs verwenden, mehrere CPE Einträge existieren können. Dies wird am folgenden Beispiel ersichtlich. Für das Beispiel soll das Paket dropbear, ein relativ schmaler Secure Shell (SSH) Server und Client, dienen. Wenn man in der NVD CPE Datenbank nach diesem Namen sucht um die dazugehörige CPE URI zu erhalten, findet man folgende Einträge: cpe:2.3:a:dropbear_ssh_project:dropbear_ssh cpe:2.3:a:matt_johnston:dropbear_ssh_server Wenn nur der Paketnamen zur Suche verwendet wird, kann nicht entschieden werden, welche CVEs zur welchen CPE zurückgeliefert werden sollen.
Um dieses Problem zu lösen, wurden die Betreuer der einzelnen Pakete im Open- Wrt Projekt dazu aufgerufen, die zum Paket dazugehörige CPE URI in der Pa- ketbeschreibung zu inkludieren. Nach dem Bau der Images sind diese Einträge in den sogenannten Manifestdateieinträgen zu finden.
Manifestdateien sind Metadateien die bei einem Build anfallen. Sie beinhalten Einträge mit Informationen zu den einzelnen Paketen. Der Quelltext 3.1 zeigt einen solchen Eintrag zum Paket dropbear. Package: dropbear Version: 2017.75-8 Depends: libc Alternatives: 100:/usr/bin/ssh:/usr/sbin/dropbear, 100:/usr/bin/scp:/usr/sbin/dropbear
26 3 Umsetzung von automatisierten Vulnerability Tests
Source: package/network/services/dropbear License: MIT LicenseFiles: LICENSE libtomcrypt/LICENSE libtommath/LICENSE Section: net CPE-ID: cpe:/a:matt_johnston:dropbear_ssh_server Architecture: x86_64 Installed-Size: 100377 Filename: dropbear_2017.75-8_x86_64.ipk Size: 101341 SHA256sum: 15d18077a83982c324d4a39db16f1562a04109da157312275f43aa31ed6ade03 Description: A small SSH2 server/client designed for small memory ↪ environments. Quelltext 3.1: Eintrag des dropbear Paketes in der Manifestdatei Hier ist das Attribut CPE-ID zu sehen, die eine CPE URI der Version 2 enthält. Durch diesen Eintrag, kann nun eine eindeutige Zuweisung von Paketnamen und CPE stattfinden.
Da diese Forderung erst kürzlich aufkam, wurde der Eintrag noch nicht in allen Paketen vollzogen. Jedoch ist eine Suche mithilfe dieser CPE URI vorzuziehen, da dadurch genauere Ergebnisse erzielt werden. Diese URI kann im Zusammen- schluss mit der ebenfalls angegebenen Version des Pakets in der Manifestdatei genutzt werden, um bekannte Schwachstellen in einer Datenbank zu suchen.
Ein Problem stellt auch die Überprüfung der großen Anzahl der Imageausprä- gungen dar. Ziel der Umsetzung ist es, die Anzahl der verwendeten Geräte so niedrig wie möglich zu halten, da die Bereitstellung und das Betreiben dieser ei- nen erhöhten Kostenaufwand darstellt. Somit muss ein Scanner gefunden werden, der beide Probleme berücksichtigt.
Der Anspruch an die einzelnen Scanner ist, mindestens Schwachstellen zu identi- fizieren. Eine Verifikation der Vulnerabilities ist nicht zwingend.
3.2.2 Prüfung der Web-Benutzerschnittstelle Zum Bereich Softwarekomponenten zählt auch die Web-Benutzerschnittstelle. Die- se benutzt viele Pakete mit bestimmten Versionen als Grundlage. Eine Webob- erfläche ist jedoch frei definierbar/gestaltbar, je nach dem was zur Konfiguration des zugrundeliegenden Geräts benötigt wird. Das hat zur Folge, dass diese in- dividuell auf Vulnerabilities überprüft werden muss. Im OpenWrt Projekt wird eine allgemeine Weboberfläche verwendet, bei der man je nach Gerät einzelne Bereiche hinzunehmen oder weglassen kann. Ein Beispiel dafür ist der Bereich, in dem Einstellungen bezüglich einer SIM-Karte getroffen werden können, wenn das Gerät eine SIM-Karte unterstützt. Wenn ein Gerät dies nicht unterstützt, wird dieser Bereich im dafür passenden Image nicht inkludiert. Dadurch kann es
27 3 Umsetzung von automatisierten Vulnerability Tests sein, das Vulnerabilities durch die Weboberfläche auf einem Gerät existieren und auf einem anderen nicht, obwohl diese die selbe Hauptoberfläche und die glei- chen Versionen der zugrundeliegenden Pakete verwenden. Zum Prüfen der Web- Benutzerschnittstelle werden üblicherweise Scanner benutzt, die einzelne Elemen- te der Webseiten analysieren und Anfragen an den Webserver des Testgerätes stellen. Die Antworten und das Verhalten des Gerätes wird dann überprüft und mit bekannten Angriffsarten verglichen. Existieren hier Überschneidungen, wer- den Hinweise darüber gegeben, ob eine bekannte Schwachstelle vorliegt oder nicht.
Ein solcher Scanner soll für die Überprüfung eines Gerätes verwendet werden, dass alle Elemente der Weboberfläche aufweist. Dafür wird der VPN-Router G3000- LW verwendet, der einen Großteil der Elemente benötigt. Um jeweils die aktuelle Firmware auf dem Gerät zu erhalten, wird ein bereits existierendes Tool verwen- det, dass die neue Firmware bei jeder Testausführung auf das Gerät flasht. Die Möglichkeit einer Hinzunahme eines weiteren Gerätes soll bei der Auswahl des Scanners berücksichtigt werden.
3.2.3 Prüfung von Verschlüsselungsalgorithmen Für einen sichere Kommunikation über eine VPN Verbindung, werden die gesen- deten Daten verschlüsselt. Die Verschlüsselung wird durch Sicherheitsprotokolle wie Transport Layer Security (TLS)/Secure Sockets Layer (SSL) in der Trans- portschicht des International Standardization Organisazation (ISO)-Open Sys- tem Interconnection (OSI) Modells verwendet. Damit eine verschlüsselte Kom- munikation mit fremden Geräten möglich ist, müssen beide den gleichen Ver- schlüsselungsalgorithmus verwenden. Um eine hohe Kompatibilität mit anderen Geräten aufzuweisen, existiert auf den Geräten eine Liste von Algorithmen, die unter dem englischen Begriff Ciphersuite bekannt ist. Um einen geeigneten Algo- rithmus zu finden, werden diese Ciphersuites verglichen. Existieren Überschnei- dungen, wird der stärkste Algorithmus ausgewählt, den beide Geräte besitzen. Verschlüsselungsalgorithmen können ebenfalls Schwachstellen aufweisen, wodurch ihre Verwendung nicht mehr empfohlen wird. Deswegen ist es nötig, die eingesetz- ten Algorithmen auf den Routern stetig nach Verwendbarkeit zu prüfen. Für solch eine Überprüfung existieren ebenfalls Scanner.
Diese Scanner erstellen an einen Port des Routers eine Anfrage für eine Kommu- nikation. Der Router teilt dann seine möglichen Verschlüsselungsalgorithmen den Scanner mit. Dieser prüft dann, ob eine Nutzung der vorgeschlagenen Algorith- men noch empfohlen wird. Diese Überprüfung wird am selben Gerät ausgeführt, das für die Überprüfung der Weboberfläche verwendet wird.
Nachdem alle Bereiche geprüft wurden, muss ein Bericht über die Resultate der
28 3 Umsetzung von automatisierten Vulnerability Tests einzelnen Überprüfungenerstellt werden. Diese müssen dann mit dem getesteten Stand der Firmware in Verbindung gebracht und archiviert werden.
Da nun alle Rahmenbedingungen zur Überprüfung feststehen, können vorhan- dene Tools geprüft werden, ob mit diesen diese Vorgehensweise umsetzbar ist.
3.3 Prüfung von existierenden Tools
Es existieren bereits Tools, die eine Überprüfung von Systemen auf Schwachstel- len ermöglichen. Die Auswahl an solcher Tools ist groß. Einige werden von einem Unternehmen entwickelt und sind nur durch ein Abonnement nutzbar, andere wiederum sind frei verfügbar und werden als Open Source Projekt entwickelt. In diesem Abschnitt betrachten wir Tools, die für eine Umsetzung der automatisier- ten Tests in Frage kommen. Im folgenden werden die zwei Vulnerability Scanner OpenVas und Nessus genauer betrachtet.
3.3.1 OpenVas und Nessus OpenVas und Nessus sind Programme die unter die Kategorie Vulnerability Scan- ner fallen. Diese Vulnerability Scanner prüfen ein Zielsystem auf bekannte Schwach- stellen mithilfe einer Datenbank, die Informationen über Vulnerabilities und Ap- plikationen enthält. Für beide Scanner sind kostenlose und kostenpflichtige Versio- nen verfügbar. Die kostenlosen sind jeweils Versionen, die nicht den vollen Umfang der kostenpflichtigen enthalten. So werden bei beiden Einschränkungen bezüglich der Datenbank und den verfügbaren Funktionen gemacht. Eine Prüfung der Scan- ner mithilfe der kostenlosen Versionen kann trotzdem vollzogen werden, da die Einschränkungen nicht unseren Anwendungsfall betreffen. Der grobe Ablauf einer Überprüfung des Zielsystems kann wie folgt beschrieben werden.
Als erstes wird dem Scanner die IP-Adresse des zu prüfenden Gerätes mitge- teilt. Ebenfalls wird angegeben, ob eine Authentifizierung auf dem Zielsystem durchgeführt werden soll. Dadurch wird gleichzeitig festgelegt, ob das System nur von Außen oder zusätzlich von Innen analysiert werden soll. Weiterhin kann an- gegeben werden, ob die zusätzliche Elemente des Systems wie zum Beispiel die Weboberfläche ebenfalls analysiert werden soll. Danach kann die automatisierte Überprüfung gestartet werden oder ein Zeitpunkt festgelegt werden, wann ein sol- che Überprüfung jeweils durchgeführt werden soll.
Der Scanner überprüft dann, welche Netzwerkschnittstellen und Ports erreichbar sind. Um festzustellen welcher Dienst hinter einem Port angeboten wird, werden erste Protokollschritte vollzogen. Mithilfe der Datenbank kann der Scanner dann anhand der empfangenen Daten ermitteln, welcher Dienst und welche Version
29 3 Umsetzung von automatisierten Vulnerability Tests hinter diesen Port zu erwarten ist. Liegt das fest, kann die Datenbank durchsucht werden, ob Schwachstellen zu diesem Dienst bekannt sind. Wurde für den Scan definiert, dass ein Login auf das System erfolgen soll, versucht sich der Scanner auf dem System einzuloggen. Gelingt dies, wird nach Applikationen und deren Versionen gesucht, die auf dem System verfügbar sind. Mit diesen Informationen wird ebenfalls mithilfe der Datenbank bekannte Schwachstellen ermittelt. Lie- gen alle möglichen Schwachstellen von der Innen- und Außenanalyse vor, wird durch den Versuch die Schwachstellen auszunutzen ermittelt, ob tatsächlich eine Vulnerability vorliegt. Zusätzlich wird die Konfiguration des Systems geprüft, ob durch diese ebenfalls Vulnerabilities existieren. Die einzelnen Ergebnisse werden dann zusammengetragen um daraus ein Bericht zu erstellen.
Die Tools bilden die in Abschnitt 2.3.1 erläuterten Phasen Informationen sam- meln, Vulnerabilities identifizieren, Resultate dokumentieren und Resultate ar- chivieren ab. Die Tools besitzen ebenfalls die Möglichkeit, einen Teil der identifi- zierten Vulnerabilities zu verifizieren.
Abbildung 3.5 zeigt das Ergebnis eines Scans durch Nessus und Abbildung 3.6 zeigt ebenfalls ein Ergebnis eines Scans durch OpenVas. Die Scans wurden auf zwei identischen Testgeräten vollzogen.
30 3 Umsetzung von automatisierten Vulnerability Tests
Abb. 3.5: Resultat eines Nessus Scans auf einem Testrouter.
Im Bild 3.5 zeigt die Zahl in den farbigen Kästchen die Anzahl der gefunde- nen Schwachstellen die dem darunter stehenden Schweregrad zugeordnet werden kann. Der erfolgreiche Abschluss des Tests zeigt, dass Nessus grundsätzlich mit den Routern umgehen kann. Die als kritisch eingestufte Schwachstelle bezieht sich auf das bereits im Quelltext 3.1 vorgestellte Paket dropbear. Nessus zeigt zu diesem Paket die in OpenWrt veröffentlichte CPE an. Das bedeutet, dass Nessus anscheinend in der Lage ist Pakete und CPEs richtig zuzuordnen. Jedoch konn- te durch weitere Tests dies nicht für andere Pakete bestätigt werden, da auch bei verschiedenen Testgeräten keine weiteren Schwachstellen erkannt wurden. Da Nessus nicht quelloffen entwickelt wird, konnte eine richtige Erkennung nicht wei- ter verifiziert werden.
Im Bild 3.6 ist zu sehen, dass OpenVas hier mehrere kritische und mittlere Schwach- stellen erkennt als Nessus. Bei genauerer Betrachtung wird jedoch ersichtlich, dass die Ursache für diese hohe Anzahl eine verwundbare Version des Softwarepaketes Apache ist. Nach einer Recherche konnte festgestellt werden, dass ein Apache Pa- ket weder installiert, noch für diese Firmwareversion verfügbar war. Ein Grund für diese Fehlinterpretation ist, dass Openwrt einen anderen Dienst an dem Port bereitstellt, der üblicherweise für den Apache Dienst genutzt wird. Der Dienst
31 3 Umsetzung von automatisierten Vulnerability Tests
Abb. 3.6: Report eines openvas CVE-Scans verhält sich ähnlich zu Apache und wird somit fälschlicherweise dort erwartet.
Nach weiteren Analysen der Tools kann folgendes Resume gezogen werden.
Beide Scanner sind in der Lage die im Abschnitt 3.2 geforderte Web-Benutzer- schnittstelle der Router automatisierte auf Vulnerabilities zu überprüfen. Eben- falls werden durch einen Scan die verwendeten SSL/TLS Verschlüsselungen auf Aktualität geprüft.
Beide Tools sind dafür geschaffen, die geforderte Paketüberprüfung durchzufüh- ren. Wie jedoch in den Beispiel gezeigt, hat OpenVas bei der Erkennung des richtigen Paketes Probleme. Da die Korrektheit einer Überprüfung somit nicht gewährleistet werden kann, scheidet OpenVas für die Umsetzung dadurch aus. Nessus hingegen, konnte ein Paket richtig erkennen, weitere Tests konnten jedoch
32 3 Umsetzung von automatisierten Vulnerability Tests eine richtige Zuordnung für andere Pakete weder beweisen noch widerlegen. Der aufgezeigte Ablauf eines Scans zeigt jedoch, dass solche Vulnerability Scanner zur Überprüfung von Systemen entwickelt wurden, die bereits in der Produktion ein- gesetzt werden. Um eine Überprüfung aller entwickelten Firmwareausprägungen ideal abzudecken sind beim Einsatz solcher Scanner ca. 25 Testgeräte nötig. Dies widerspricht jedoch der gestellten Forderung, die Anzahl der Testgeräte so gering wie möglich zu halten.
Des Weiteren können beide Scanner nicht auf individuelle Bedürfnisse angepasst werden, wie zum Beispiel einem Fuzzer Modul, das eine Analyse bezüglich unbe- kannter Schwachstellen ermöglicht. Somit scheiden beide Scanner für die Umset- zung der automatisierten Vulnerability Tests aus.
Da weitere Recherchen keine weiteren Tools hervorbrachte, die eine Automati- sierung ermöglichen, werden wir vor die Herausforderung gestellt, ein alternatives System zu entwickeln. Die dafür nötigen Anforderungen an das System werden im nächsten Abschnitt erarbeitet.
3.4 Anforderungen an die Architektur des Systems
Im vorherigen Abschnitt konnten die geprüften Tools keine Abhilfe für ein Um- setzung der Arbeit schaffen. Um ein System zu entwerfen, das der gewünschten Vorgehensweise entspricht, müssen weitere und detailliertere Anforderungen an das System festgelegt werden. Dafür werden die Anforderungen in die Bereiche Automatisierbarkeit, Modularität und Schnittstellen zur Kommunikation aufge- teilt. Als erstes gilt es die Automatisierbarkeit genauer zu betrachten.
3.4.1 Automatisierbarkeit Sie ist eine der wichtigsten Anforderungen, da der Fokus der Arbeit darauf liegt. Unter Automatisierbarkeit ist gemeint, dass nur die Ausführung der Überprüfung gestartet werden muss, die Überprüfung jedoch selbst keine Interaktion von ei- ner Person erfordert. Das System muss also die Ausführung der Überprüfung der Bereiche Pakete, Verschlüsselungsalgorithmen, Web-Benutzerschnittstelle selbst anstoßen, beziehungsweise selbst übernehmen. Das Anstoßen der Gesamtausfüh- rung soll flexibel sein. Dies hat zur Folge, dass das System mehrere Varianten für das Auslösen der Tests implementieren muss. Wie bei Nessus und OpenVas bereits gesehen sind die gängigsten Varianten dafür das festlegen eines Zeitpunktes oder Zeitintervalls oder das Anstoßen durch eine manuelle Interaktion. Da die Tests Entwicklungsbegleitend laufen sollen, wäre hier eine Ereignis getriebene Variante von Vorteil. Diese kann beispielsweise zum Einsatz kommen, wenn ein Repository wie GitHub zur Verwaltung des Projektes verwendet wird. Wird dort eine Ände-
33 3 Umsetzung von automatisierten Vulnerability Tests rung am Projekt vorgenommen, kann ein Ereignis ausgelöst werden. Ein solches Ereignis kann das Senden eines Start Befehls an das Testsystem sein. Dadurch kann ermittelt werden, welche Auswirkungen jede Änderung der Software bezüg- lich der Angreifbarkeit des Systems hat. Dafür sind wiederum Schnittstellen zum Testsystem notwendig. Für die Automatisierbarkeit können somit folgende Anforderungen festgehalten werden. • Das System muss die Überprüfung der einzelnen Bereiche selbstständig durch- führen. • Das Auslösen einer Überprüfung muss durch folgende Varianten ermöglicht werden: – Auslösen durch Nutzerinteraktion. – Auslösen durch festlegen eines Zeitpunktes oder einem Intervall. – Auslösen der Tests durch ein Ereignis von außerhalb.
3.4.2 Modularität Eine weitere Anforderung an das System ist, das es eine hohe Modularität auf- weisen muss. Unter Modularität versteht man, dass Komponenten des Systems leicht ausgetauscht oder neue hinzugefügt werden können. Eine Komponente kann beispielsweise ein Programm sein, dass die Überprüfung der Softwarepakete über- nimmt.
Dies ist notwendig, da zum Beispiel für die Überprüfung eines neuen Routermo- dels andere Anforderungen gestellt werden, die nur durch Integration einer neuen Komponente erfüllt werden können. Des Weiteren können Komponenten, für die eine bessere Alternative veröffentlicht wurde, einfach ausgetauscht werden. Eben- so können durch diese Eigenschaft Tools hinzugefügt werden, die beispielsweise eine statische Quellcodeanalyse für Softwarepakete durchführen. Das Tauschen oder neues Hinzufügen muss ohne großem Aufwand möglich sein.
Dies kann erreicht werden, wenn die einzelnen Module vom Testsystem aufgeru- fen werden können. Hierbei darf es jedoch keine Rolle spielen, ob sich die Module auf oder außerhalb des Testsystems befinden. Module außerhalb des Systems soll über eine Application programming interface (API) Aufgerufen werden können. Module auf dem System müssen so konstruiert sein, dass diese auch ohne dem Testsystem verwendet werden können. Dadurch kann das zugrundeliegende Sys- tem ebenfalls gewechselt werden, ohne die Module anpassen zu müssen.
Ebenfalls muss eine Gruppierung der einzelnen Module möglich und frei wähl- bar sein. Dies ist nötig, da es ein zusammenlegen von Modulen bezüglich ihrer
34 3 Umsetzung von automatisierten Vulnerability Tests
Aufruffrequenz oder der Laufzeit ermöglicht. Dadurch ist zum Beispiel ein Zusam- menlegen der Module zur Überprüfung der Pakete und der Verschlüsselungsalgo- rithmen möglich. Diese können dann bei jeder Änderung am Projekt ausgelöst werden wobei die Überprüfung der Web-Benutzerschnittstelle nur jeweils einmal täglich erfolgt.
Dadurch ergibt sich zusammenfassend folgende Anforderungen bezüglich der Mo- dularität. • Module müssen ohne großen Aufwand ausgetauscht/hinzugefügt werden kön- nen. • Module können sich sowohl auf und außerhalb des Testsystems befinden. • Die Module müssen eigenständig verwendbar sein. • Das Testsystem, dass den Aufruf der einzelnen Module übernimmt, muss selbst austauschbar sein. • Die beliebige Gruppierung der einzelnen Module muss möglich sein. • Der Aufruf der einzelnen Gruppen muss möglich sein.
3.4.3 Schnittstellen zur Kommunikation Da einzelne Module oder Modulgruppen auch durch Ereignisse von außerhalb des System ausgelöst werden können, müssen dafür Schnittstellen zur Kommunika- tion mit dem Testsystem bereitgestellt werden. Dies muss so gestaltet sein, dass ein Aufruf einer Überprüfung direkt angestoßen werden kann, oder das Testsys- tem anhand der empfangenen Daten entscheidet, ob eine Ausführung erfolgen soll.
Ebenfalls muss eine Kommunikation zwischen den einzelnen Modulen stattfinden können. Dies ist notwendig, da ein Modul eventuell die Resultate eines vorherigen Moduls benötigt. Deshalb muss das Testsystem die Möglichkeit bieten, einzelne Ergebnisse zwischenspeichern zu können. Diese Ergebnisse können dann im spä- teren Verlauf der Überprüfung von anderen Modulen genutzt werden. Somit ist das Testsystem selbst eine Schnittstelle.
Ein Benutzer des Testsystems muss ebenfalls schnell und einfach mit diesem in- teragieren können. Dadurch soll ermöglicht werden, Überprüfungen manuell aus zu lösen oder eine Übersicht über den Verlauf der Scans zu erhalten. Dies soll für mehrere Nutzer möglich sein, die jeweils die gleichen Informationen bereitgestellt bekommen. Eine ideale Umsetzung der genannten Punkte bietet eine Web-Benut- zerschnittstelle, wie sie auch bei Nessus oder OpenVas zu finden ist.
35 3 Umsetzung von automatisierten Vulnerability Tests
Treten Fehler während der Ausführung auf oder ist diese beendet, muss eine Mög- lichkeit existieren, eine für die Überprüfung verantwortliche Person darüber zu informieren. Dies kann zum Beispiel durch das Senden einer Nachricht geschehen. Dafür muss im Testsystem definierbar sein, wann und wie eine Nachricht gesendet werden soll. Eine Benachrichtigung bei einem automatisierten Ablauf ist wichtig, da sonst dieser unmerklich im Hintergrund ausgeführt wird und deshalb die Über- prüfung der Ergebnisse vergessen wird.
Anforderungen an die Schnittstellen des Testsystems sind somit folgende: • Das Testsystem muss eine Schnittstelle bieten, die einen Aufruf der Über- prüfung von außerhalb ermöglicht. • Das Testsystem muss eine Schnittstellen bieten um eine Kommunikation zwischen den Modulen zu ermöglichen. • Durch das Testsystem muss es möglich sein, Benachrichtigungen an Personen zu senden. • Das Testsystem muss eine Web-Benutzerschnittstelle haben.
3.4.4 Konfigurierbarkeit Alle bisherigen genannten Anforderungen fordern implizit eine hohe Konfigurier- barkeit des Testsystems. Hierbei ist es egal ob die Konfiguration über eine Da- tei oder über die Web-Benutzerschnittstelle vorgenommen werden kann, solange dies einfach und ohne großen Aufwand zu bewerkstelligen ist. Das System muss ebenfalls in der Lage sein, eine Änderung der Konfiguration schnellstmöglich um- zusetzen, auch wenn derweilen eine Überprüfung läuft. Dies findet Anwendung, wenn beispielsweise ein weiteres Modul vor der nächsten Überprüfung eingebun- den werden soll. Bezüglich der Konfigurierbarkeit ergeben sich somit folgende Anforderungen: • Das System muss einfach und ohne großen Aufwand konfigurierbar sein. • Änderungen der Konfiguration müssen schnell anwendbar sein. Da nun alle Anforderungen an das Testsystem gestellt wurden, kann zur Umset- zung dieser vorangegangen werden.
3.5 Umsetzung der Anforderungen
Aus den gestellten Anforderungen des Systems wird ersichtlich, dass ein Grund- system erforderlich ist, dass die Integration von Modulen ermöglicht. Bei einer Recherche nach einem solchen kristallisierte sich das Framework Buildbot heraus,
36 3 Umsetzung von automatisierten Vulnerability Tests dass im Unternehmen auch für den Bau der Firmware verwendet wir. Warum ausgerechnet dieses in Frage kommt, wird im folgenden Abschnitt erklärt.
3.5.1 Buildbot als Grundlage Buildbot ist ein System zur Automatisierung des Bau- und Testzyklus von Soft- ware. Es basiert auf der Programmiersprache Python und wird als Open Source Projekt entwickelt. Die Abbildung 3.7 zeigt den schematischen Aufbau des Sys- tems.
Abb. 3.7: Schematischer Aufbau von Buildbot Quelle: [3]
Es ist zu erkennen, dass der Aufbau das Prinzip Master Worker verfolgt. Der Master dient dazu die ihm unterstellten Worker zu koordinieren und mit Tätigkei- ten zu versorgen. Der Master bekommt meist von außerhalb Informaitonen über Änderungen in einem Repository, von denen er abhängig macht, welche Tätigkei- ten von den Workern ausgeführt werden müssen. Aus Abbildung 3.7 ist ebenfalls zu erkennen, dass der Master durch sogenannte Notifiers über die Möglichkeit verfügt, Benachrichtigungen an eine äußere Instanz zu senden. Der Master gibt die auszuführenden Befehle nur an einen Worker weiter, sodass der Worker die volle Ausführung der Tätigkeiten übernimmt. Die im Abschnitt 3.4 gestellten Anforderungen bezüglich reagieren auf äußerliche Ereignisse und dem Senden von Benachrichtigen sind somit erfüllt.
Eine tiefere Betrachtung der Konfigurationsmöglichkeiten zeigt, dass die Kon- figurationselemente Hook, Scheduler, Builder, Buildsteps und Reporter fast alle weiteren Anforderungen erfüllen können.
37 3 Umsetzung von automatisierten Vulnerability Tests
Durch Hooks kann konfiguriert werden, wie von außen mit dem System kom- muniziert werden kann. Dies inkludiert nicht die Web-Benutzerschnittstelle. Üb- licherweise wird ein Hook für ein Web-Versionsverwaltungstool wie beispielsweise GitHub verwendet. Der Hook kann jedoch so personalisiert werden, dass dieser auch für das Auslösen von Vulnerablity Scans verwendet werden kann. Empfängt das System einen Hook wird dieser bearbeitet und an einem sogenannten Sche- duler weitergegeben.
Durch einen Scheduler kann festgelegt werden, welcher Builder für die Aufga- benumsetzung zuständig ist und wann dieser Builder aufgerufen werden soll. Eine Aktivierung eines Schedulers ist auch über die Web-Oberfläche des Systems mög- lich. Ebenfalls ist es möglich einen Zeitpunkt zu definieren, an dem der Builder aufgerufen werden soll. Erfüllt eine Anfrage alle notwendigen Parameter, gibt der Scheduler die Anfrage an den Builder weiter, der diese in eine Warteschlange stellt.
Die Konfiguration eines Builders definiert, welche sogennante BuildFactory ver- wendet werden soll. Dieses Element enthält den genauen Ablauf eines Builds durch Angabe der verwendeten Buildsteps. Eine BuildFactory ist für das Instanzieren der einzelnen Builds zuständig. Des Weiteren wird bei einem Builder angege- ben, auf welchem Worker die einzelnen Schritte ausgeführt werden sollen. Ist der Worker frei, wird dieser verwendet um den Build zu vollziehen. Bei Aufruf des Builders, fürt dieser dann genau die angegebenen Buildsteps aus.
In einem Buildstep wird angegeben, welcher Befehl ausgeführt werden soll. Ein Befehl ist hier üblicherweise der Aufruf eines weiteren Programms. Für die Befe- le können Parameter aus anderen Buildsteps notwendig sein, die als sogenannte Properties zwischengespeichert werden können. Wenn ein solcher Eintrag genutzt werden will, wird dies ebenfalls in der Definition des Schrittes mit angegeben. Buildbot ermöglicht dadurch die Kommunikation über mehrere Schritte hinweg. Durch die Definition solcher Befehle können Module je nach Bedarf in das System integriert und durch Builder gruppiert werden, was wiederum den vorher gestell- ten Anforderungen entspricht.
Ist ein Build beendet, gibt dieser Informationen über den Build an einen Repor- ter, in Abbildung 3.7 dargestellt als Notifier, weiter. Bei diesem kann konfiguriert werden, welche Nachricht an wen gesendet wird. Eine Benachrichtigung kann auch beim Start eines Builds versendet werden.
Das beschriebene Zusammenwirken der einzelnen Konfigurationselemente soll die Abbildung 3.8 nochmals verdeutlichen.
38 3 Umsetzung von automatisierten Vulnerability Tests
Abb. 3.8: Schematisches Zusammenspiel der Einzelnen Komponenten Quelle: [2]
Die einzelnen Konfigurationen können über eine Datei vorgenommen werden. Eine Änderung kann dann durch Ausführen eines Befehls auf Fehler überprüft und danach angewendet werden. Der nächste gestartete Builder verwendet dann diese neue Konfiguration.
Da Buildbot auch über eine Weboberfläche durch den Master verfügt, können Builds über diese verwaltet werden. Alle genannten Konfigurationsobjekte und die Weboberfläche erfüllen die im Abschnitt 3.4 geforderten Anforderungen. Deshalb wird Buildbot weiter für die Umsetzung verwendet. Wie die einzelnen Elemente
39 3 Umsetzung von automatisierten Vulnerability Tests für die Umsetzung konfiguriert werden müssen, wird in Abschnitt 3.5.3 genauer dargestellt.
Da nun das zu grundelegende System feststeht, müssen Scanner Tools ausgewählt werden, die die Überprüfung der einzelnen Bereiche übernehmen.
3.5.2 Scanner Tools Nun müssen Tools ausgewählt werden, die in den Buildbot integrierbar sind. Bei der Auswahl muss auch darauf geachtet werden, ob die im Abschnitt 2.3.2 festge- legten Phasen des Penetrationstests Umsetzbar sind.
Arachni Eine Überprüfung der Weboberfläche erfolgt durch Anfragen eines Clients (Tool) an den Webserver des Testgeräts. Zur Überprüfung der Weboberfläche stehen viele Tools zu Verfügung. Diese enthalten zur Überprüfung Programme, Client fungieren. Der Server ist der Webserver auf dem zu analysierende System. Die meisten Tools sind eigenständige Systeme, die selbst eine Web-Benutzerschnitt- stelle verfügen. Diese dient zur Konfiguration des Tools. Hier wird angegeben, welches Zielsystem auf welche Schwachstellen überprüft werden soll. Danach kann ein Scan manuell angestoßen werden. Die wenigsten Tools darunter verfügen über eine Möglichkeit den Scan automatisiert auszulösen.
Arachni ist ein Tool zur Überprüfung von Web-Benutzerschnittstellen, das weit verbreitet genutzt wird und ein automatisiertes Auslösen von Scans erlaubt. Es ist ein Framework auf der Basis der Programmiersprache Ruby, das ebenfalls eine Representational State Transfer (REST) API bietet, mit der die Überprüfungen auch automatisiert von außen erfolgen kann. Da es auf Ruby basiert, kann das eigenständige System beiwpielsweise einfach auf einer virtuellen Maschine bereit- gestellt werden.
In Buildbot kann Arachni durch den Aufruf eines Scriptes verwendet werden, das die notwendigen API-Aufrufe tätigt. Somit bildet das Script das zu integrie- rende Modul. Das Script wird in Python umgesetzt, da diese Programmiersprache für seine gute Lesbarkeit und einfache Ausführbarkeit auf verschiedenen Systemen bekannt ist. Es ist lediglich der Python Interpreter notwendig, der die Befehle im Script liest und diese dann ausführt. Da Buildbot, der ebenfalls den Python In- terpreter benötigt, als Grundsystem verwendet wird, ist der Interpreter bereits auf dem System vorhanden.
Folgende Anfragen an die REST-Schnittstelle über das Hyper Text Transfer Pro- tokoll (HTTP) sind für die Umsetzung wichtig.
40 3 Umsetzung von automatisierten Vulnerability Tests
1. POST /scans 2. GET /scans/
# Angabe der URL des Arachni Servers mit Portnummer der REST -Schnittstelle url = 'http://arachni -scanner.de:7331' headers = {'Content -type': 'application/json', 'Accept': 'text/plain'} # Angabe der URL des Zielsystems in einem Dictonary , das später # in JSON -Format umgewandelt wird. payload = {'url': 'https://zielsystem.de'}
# POST Anfrage an die REST -Schnittstelle r = requests.post(url + '/scans', data=json.dumps(payload), headers=headers) Quelltext 3.2: Beispiel einer Anfrage zum Starten eines Scans, an die REST- Schnittstelle von Arachni War die Anfrage erfolgreich, erhält man die Identifikationsnummer des Scans in einem JSON-Objekt zurück. Diese muss dann ausgelesen werden und für weitere Anfragen bezüglich dieses Scans zwischengespeichert werden.
Um dann den Status des gestarteten Scans zu erfragen, muss die 2. Anfrage (GET /scans/
41 3 Umsetzung von automatisierten Vulnerability Tests
"burst_average_response_time": 0, "total_average_response_time": 0.12118887582781, "max_concurrency": 20, "original_max_concurrency": 20 }, "browser_cluster":{ "seconds_per_job": 1.6666666666667, "total_job_time": 25, "queued_job_count": 31, "completed_job_count": 15 }, "runtime": 9.251885252, "found_pages": 10, "audited_pages": 2, "current_page":"https:\/\/ zielsystem.de\/ajax\/popular?offset=0" }, "errors":[], "messages":[], "issues":[], "sitemap":{} } Quelltext 3.3: Beispielantwort einer Anfrage bezüglich des Status des Scans Dieser Status kann nun solange abgefragt werden, bis dieser auf den Wert ”done” wechselt. Danach kann durch die 3. Anfrage (GET /scans/
# GET REST -API Anfrage für download senden r = requests.get(url + '/scans/' + scan_id + '/report.html.zip')
if r.status_code == 200: # wenn Anfrage erfolgreich war, Report speichern filename = 'arachni_scan_' + scan_id + '.zip'
with open(filename , 'wb') as f: f.write(r.content) else: exit("Report␣could't␣be␣downloaded.␣Status␣Code:␣" + str(r. ↪ status_code)) Quelltext 3.4: Beispiel einer Anfrage zum download eines Scans, an die REST- Schnittstelle von Arachni Abbildung 3.9 zeigt einen Beispielausschnitt eines Hypertext Markup Langua- ge (HTML) Report eines Arachni Scans. Bei einem Scan, sammelt Arachni alle Links auf den erhaltenen Websiten. Diese werden dann gefilter, damit nur Links zu dem ausgewählten Zielsystem übrig bleiben. Somit erhält Arachni eine Liste von erreichbaren URLs für diesen Zielsystem, die dann ebenfalls analysiert wer- den. Bei der Durchführung des ersten Scans zeigte sich, dass die Weboberfläche
42 3 Umsetzung von automatisierten Vulnerability Tests
Abb. 3.9: Beispielausschnitt eines Arachni HTML-Report Quelle: [1] der Router ständig aktualisiert wird. Dies geschieht dadurch, dass der Client der Weboberfläche des Routers eine URL an den Webserver des Routers sendet, der eine eindeutige ID angehängt ist. Dadurch entsteht eine große Liste von URLs, die für die Überprüfung keine Relevanz haben und die Scandauer erheblich erhöhen. Durch Angabe eines regulären Ausdrucks in der Konfiguration zu diesem Scan werden diese von Arachni ausgefiltert.
Des Weiteren kann in der Konfiguration auch angegeben werden, ob sich Arachni durch einen Benutzernamen und ein Passwort in der Benutzeroberfläche anmelden soll. Dies ist notwendig, damit alle verfügbaren Seiten auf Vulnerabilities geprüft werden können. Die erstellte Konfiguration kann dann beim Start eines Scans im JSON-Format mithilfe der REST-API übertragen werden.
Arachni kann mithilfe des angedeuteten Scripts in den Buildbot als Buildstep integriert werden. Das komplette Script ist auf der beiliegenden CD im Verzeich- nis Arachni zu finden. Durch dieses Script übernimmt Buildbot den Aufruf der
43 3 Umsetzung von automatisierten Vulnerability Tests
Überprüfung und Arachni den automatisierten Scan der Web-Benutzerschnitt- stelle eines Routers. Da somit eine automatisierte Prüfung der Web-Benutzer- schnittstelle umsetzbar ist, muss ein Tool für die Umsetzung der Überprüfung der Verschlüsselungsalgorithmen gefunden werden.
Nmap Eine verschlüsselte Kommunikation durch die Netzwerkschicht benötigt Verschlüs- selungsalgorithmen, die durch Anfragen an den Netzwerkschnittstellen bereit ge- stellt werden. Dafür muss ein Scanner Anfragen auf einem Port einer Netzwerk- schnittstelle des Routers stellen. Um solche Anfragen zu tätigen existieren soge- nannte Portscanner. Der bekannteste Vertreter ist Nmap. Dieser wird benutzt, um verschiedene Hosts und deren bereitgestellten Dienste in einem Computer- netzwerk aufzuspüren.
Nmap besitzt ein Plugin System für Scripte, die es ermöglichen die Funktionali- tät von Nmap zu erweitern. Ein bereits inkludiertes Script ist ”ssl-enum-ciphers”. Dies dient zur Überprüfung der Verschlüsselungsalgorithmen. Nmap wird über die Kommandozeile aufgerufen. Um die Ciphersuit auf Aktualität zu prüfen, wird folgender Befehl verwendet. nmap --script ssl-enum -ciphers -p 443 192.168.000.1 Quelltext 3.5: Nmap Befehl mit Parameter für Überprüfung der Ciphersuit auf Aktualität Hier wird mit dem parameter -p angegeben, dass auf diesem Port die Ciphersuit überprüft werden soll. Die danach folgende IP-Adresse ist die Adresse des zu über- prüfenden Hosts. Ein Scan eines Routers mit diesem Befehl kann beispielsweise zu folgendem Ergebnis führen. Starting Nmap 7.01 ( https://nmap.org ) at 2019-02-26 15:59 CET Nmap scan report for example.com (192.168.0.1) Host is up (0.0020s latency). PORTSTATESERVICEVERSION 443/tcp open ssl/http Example.com http config | ssl-enum-ciphers: | TLSv1.0: | ciphers: | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1536) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1536) - A | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: server | warnings:
44 3 Umsetzung von automatisierten Vulnerability Tests
| Key exchange parameters of lower strength than certificate key | TLSv1.1: | ciphers: | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1536) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1536) - A | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: server | warnings: | Key exchange parameters of lower strength than certificate key | TLSv1.2: | ciphers: | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 1536) - A | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 1536) - A | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1536) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1536) - A | TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 1536) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 1536) - A | TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A | compressors: | NULL | cipher preference: server | warnings: | Key exchange parameters of lower strength than certificate key |_ least strength: A Service Info: Device: broadband router Quelltext 3.6: Ergebnis eines nmap ssl-enum-ciphers Scans Unter den Bereichen warnings können dann Hinweise auf Schwächen der verwen- deten Ciphers gefunden werden, beispielsweise wenn ihre Verwendung nicht mehr empfohlen wird.
Auf allen Imageausprägungen der OpenWrt Firmware werden an jedem Port, an dem SSL/TLS verwendet wird, die selben Ciphers benutzt. Somit können alle Images durch Überprüfen der Algorithmen an einem Port eines Testgeräts ab- gedeckt werden. Da für die Web-Benutzerschnittstellenprüfung bereits ein Gerät
45 3 Umsetzung von automatisierten Vulnerability Tests benötigt wird, kann dieses für den Test durch Nmap verwendet werden.
Da der Nmap Befehl als Buildstep in Buildbot ausgeführt werden kann, ist ei- ne Integration dieses Moduls möglich. Somit steht Nmap für die automatisierte Überprüfung der Verschlüsselungsalgorithmen fest. Nun muss ein Tool für das au- tomatisierte Scannen der Softwarepakete auf bekannte Vulnerabilities gefunden werden. cve-indicator Wie bereits im Abschnitt 3.2.1 aufgezeigt, liegt die Hauptherausforderung darin, trotz der großen Anzahl der verschiedenen Firmwareausprägungen eine minimale Anzahl von Routern bereitstellen zu müssen, um alle Softwarepakete auf bekannte Vulnerabilities zu überprüfen. Des Weiteren gibt es Probleme bei der eindeutigen Zuordnung von Paketname und CPE um mit diesem nach CVEs zu suchen.
Eine Recherche nach einem Tool, das Abhilfe für diese Probleme schaffen kann ergab keinen Erfolg. Deshalb muss selbst ein Tool entwickelt werden, dass in das Buildbot System integriert werden kann. Daraus entstand das von mir im Zuge der Bachelorarbeit entwickelte Kommandozeilenprogramm cve-indicator. Der dazugehörige Quelltext ist auf der beiliegenden CD oder auf GitHub un- ter https://github.com/kkreitmair/cve-indicator zu finden. cve-indicator ist ein auf Python basiertes Tool, das folgende drei Hauptkomman- dos besitzt. • cve-indicator gen-list • cve-indicator get-cves • cve-indicator gen-rprt Der Befehl cve-indicator gen-list durchsucht ein gegebenes Verzeichnis nach- Manifestdateien ab, in denen die Paketeinträge, wie im Quelltext 3.1 vorgestellt, enthalten sind. Die Manifestdateien fallen beim Bau der Images an. Sie werden pro Architektur, beispielsweise x86_64, zusammengelegt. Somit ergibt sich folgende Verzeichnisstruktur, die nach Manifestdateien durchsucht werden muss. files |– packages |– x86_64 |– base | |– Packages.manifest |– gluon_packages | |– Packages.manifest |– luci | |– Packages.manifest
46 3 Umsetzung von automatisierten Vulnerability Tests
|– luci2 | |– Packages.manifest |– management | |– Packages.manifest |– openwisp_config | |– Packages.manifest |– packages | |– Packages.manifest |– routing | |– Packages.manifest |– tdt_kernel_packages | |– Packages.manifest |– tdt_luci2_addons | |– Packages.manifest |– tdt_luci_addons | |– Packages.manifest |– tdt_luci_manual | |– Packages.manifest |– tdt_packages | |– Packages.manifest |– tdt_packages_private | |– Packages.manifest |– tdt_packages_support | |– Packages.manifest |– tdt_thirdparty | |– Packages.manifest |– tdt_upgrade | |– Packages.manifest |– telephony |– Packages.manifest Quelltext 3.7: Verzeichnisstruktur für Manifestdateien Architektur x86_64 Die darin enthaltenen Paketeinträge werden durchlaufen. Es werden alle Pakete mit einem CPE Eintrag ausgelesen. Es wird der Name des Paketes und die CPE, mit Versionsnummer versehen, in einer JavaScript Object Notation (JSON) Datei gespeichert. Diese Datei enthält jeweils eine Sektion für Metadaten und Pakete. Unter Metadaten werden Daten festgehalten, die den Scan betreffen. Im Bereich der Pakete werden die Pakete aufgelistet, die einen CPE Eintrag besitzen. Da aus einem Paket mehrere Unterpakete entstehen können, werden diese dort ebenfalls vermerkt. Diese JSON Datei fungiert als Bericht zum Scan. Der Quelltext 3.8 zeigt eine verkürzte Version eines solchen Reports. { "meta_data": { "cpe_list_generator_data": { "application": "cve-indicator 0.0.1", "packages_total": 1139, "packages_with_cpe_id": 35, "project": "openwrt", "report_filename": "indicator-gen_list-482cd95.json", "report_id":
47 3 Umsetzung von automatisierten Vulnerability Tests
"482cd954e7eb0778d946223a74bb7e0- ↪ dd207445c1e75b92965f214197bcdc164", "timestamp": "2019-01-18T16:38:03" } }, "packages": { "binutils": { "cpe": "cpe:/a:gnu:binutils:2.27", "sub_packages": [ " libbfd" ], "version": "2.27" }, "bzip2": { "cpe": "cpe:/a:bzip:bzip2:1.0.6", "sub_packages": [ " bzip2", " libbz2" ], "version": "1.0.6" } } } Quelltext 3.8: JSON Datei, die die Erbenisse des Befehls cve-indicator gen-list enthalten Diese Daten werden dann durch Aufruf des Befehls cve-indicator get-cves zur Suche nach bekannten Vulnerabilities verwendet. cve-indicator durchläuft dann die einzelnen Pakete des packages Segments, ent- nimmt die CPE und führt mithilfe dieser einen API-Aufruf zum Tool cve-search durch, welches im Abschnitt 3.5.2 genauer dargestellt wird. cve-search liefert dann alle bekannten Schwachstellen zu dieser CPE zurück. Wurden alle Pakete durch- laufen, wird ebenfalls eine JSON Datei erstellt, die auch eine Metadaten und Paket Sektion enthält. Im Bereich der Metadaten werden die Daten aus der vorherigen JSON Datei und die Daten des get-cves Scans festgehalten. Die Paket Section enthält nun alle Pakete, zu denen CVEs gefunden wurden, welche dies sind, und den CVSS dazu. Quelltext 3.9 zeigt ebenfalls eine verkürzte Version des Reports. { "meta_data": { "cpe_list_generator_data": { "application": "cve-indicator 0.0.1", "packages_total": 1266, "packages_with_cpe_id": 35, "project": "openwrt", "report_filename": "indicator-gen_list-28ef936.json", "report_id": "28ef936d6eefd9ceadfc61594417ee120c-2616319 ↪ e6d9266a662e07d2d700476",
48 3 Umsetzung von automatisierten Vulnerability Tests
"timestamp": "2019-01-13T15:41:02" }, "cve-indicator_get-cves": { "api_url": "http://192.168.117.105/api/cvefor/", "application": "cve-indicator 0.0.1", "cves_total": 20, "pkgs_with_cves": 5, "report_filename": "indicator-get_cves-8ec0607.json", "report_id": "8ec0607fd674b012c0b63611a97b1d1c-68759006 ↪ cd2d745adc927b47bfd552aa", "time_needed": "00:00:38", "timestamp": "2019-01-13T15:41:39" } }, "packages": { "bzip2": { "cpe": "cpe:/a:bzip:bzip2:1.0.6", "cves": { "CVE-2016-3189": { "cvss": 4.3, "cvss-time": "2016-07-01T12:43:50.873000" } }, "version": "1.0.6" }, "grub2": { "cpe": "cpe:/a:gnu:grub2:2.02", "cves": { "CVE-2015-8370": { "cvss": 6.9, "cvss-time": "2016-03-29T11:04:49.907000" } }, "version": "2.02" } } } Quelltext 3.9: Daten im JSON-Format, die die Ergebnisse der Ausführung des Befehls cve-indicator get-cves enthalten. Durch den ersten Report (Quelltext 3.8) wird ersichtlich, welche Pakete analy- siert wurden. Durch den zweiten Report (Quelltext 3.9) wird ersichtlich, welche Pakete von Schwachstellen betroffen sind. Beide Berichte wurden im JSON For- mat strukturiert, sodass die darin enthaltenen Daten durch andere Tools weiter verwertbar sind. Der erste Report muss nicht zwingend vom cve-indicator Tool erzeugt werden, solange das gleiche Schema zur Strukturierung der Daten verfolgt wird.
Die wesentlichen Fakten des letzten Reports sind für einen Menschen kaum leser-
49 3 Umsetzung von automatisierten Vulnerability Tests lich. Darum kann mit dem Befehl cve-indicator gen-rprt eine HTML Version des Reports erzeugt werden. Abbildung 3.10 zeigt einen Teil eines solchen Reports.
Abb. 3.10: Teil eines cve-indicator HTML Reports
Im Report wird durch die Angabe der Metadaten genau ersichtlich, auf welcher Grundlage die Prüfung geschehen ist. Darunter werden alle Pakete aufgelistet, zu denen eine Vulnerability gefunden wurde. Auch wird die Schwere der jeweiligen Schwachstelle durch den CVSS Wert angegeben. Die angegebenen CVE-IDs sind mit einem Link versehen. Dieser verweist direkt auf die Webseite des CVE Ein- trags auf der cve-search Weboberfläche. Dort sind Informationen wie beispiels-
50 3 Umsetzung von automatisierten Vulnerability Tests weise der dazugehörige CWE zum CVE Eintrag zu finden. Dadurch wird eine einfachere Verifizierung ermöglicht.
Durch das Tool cve-indicator kann somit ohne jeglichen Bedarf an Testgeräten für Architekturen nach bekannten Vulnerabilities gesucht werden. Ebenfalls schafft es eine direkte Zuordnung zwischen Paketen und CVEs, da es die CPE direkt aus den Paketinformationen verwendet. Die Anzahl der Pakete mit einem CPE Ein- trag im OpenWrt Projekt nehmen stetig zu, sodass eine Abdeckung aller Pakete in Aussicht ist.
Das Tool kann ebenfalls leicht in den Buildbot integriert werden. Die einzelnen Befehle werden als Buildstep definiert und miteinander kombiniert. Das Verzeich- nis, in dem die benötigten Manifestdateien liegen befinden sich auf einem File Transfer Protocol (FTP) Server. Dieses kann mithilfe des mount Tools in das Verzeichnis des ausführenden Workers integriert werden.
Die bis hierhin vorgestellten Tools fokusieren sich auf die Informationsbeschaf- fung und Schwachstellenidentifikation. cve-indicator nutzt zur Suche von CVEs das Tool cve-search, dessen Nutzung im folgenden Abschnitt genauer dargelegt wird. cve-search cve-search ist ein auf Python basierendes Tool, mit einer Datenbank, die mehre- re Vulnerabilities bezogene Unterdatenbanken beinhaltet. Darunter fällt die NVD Datenbank, di die CVE, CPE und CWE Verzeichnisse enthält, oder beispielsweise auch die exploitdb von Offensive Security. Das Hauptaugenmerk liegt darauf, dass diese Datenbanken zusammengefasst werden. Dadurch liegen mehr Daten über ei- ne Vulnerability vor, welche dann zentralisiert durchsucht werden können. Da der Dienst auch selbst betrieben werden kann, ermöglicht dies die Geheimhaltung der Suchanfragen und der Resultate. Ebenso weist cve-search eine Web-Benut- zerschnittstelle auf. Durch diese kann die Datenbank manuell durchsucht werden. Dies ermöglicht auch, dass jeder Benutzer die gleichen Informationen bezüglich einer Vulnerability erhält und dadurch eventuelle Irrtümer, bei einer Diskussion über die Vulnerability, vermieden werden können.
Den größten Vorteil bietet jedoch die Web-API Schnittstelle, da dadurch eine Automatisierung einer Abfrage erfolgen kann. Bei der Umsetzung der Arbeit ge- schieht dies mit dem Tool cve-indicator das im vorherigen Abschnitt 3.5.2 genauer dargestellt wurde.
Der wichtigste API-Aufruf für die Umsetzung der Arbeit ist GET /api/cve- for/
51 3 Umsetzung von automatisierten Vulnerability Tests ten Python Code umgesetzt werden. import requests import json
api_url = 'http://cve-search.de/api/cvefor/' cpe_str = 'cpe:/a:bzip:bzip2:1.0.6'
r = requests.get(api_url + cpe_str)
if r.status_code == '200': cpe_response = r.json() Quelltext 3.10: Beispiel einer API-Anfrage an cve-search, um alle CVEs zu einer gegebenen CPE zu erhalten Ist die Anfrage erfolgreich, wird eine Liste von CVEs zurückgegeben, die mit der gegebenen CPE in Verbindung stehen. Der Quelltext 3.11 zeigt eine verkürzte Antwort auf eine API-Anfrage. [ { "cvss": 7.5, "cvss-time": { "$date": 1117762800000 }, "id": "CVE-2005-0100", "impact": { "availability": "PARTIAL", "confidentiality": "PARTIAL", "integrity": "PARTIAL" }, ... Quelltext 3.11: Antwortdaten im JSON-Format, erhalten von cve-search nach einer Suche über die API von cve-search. Diese werden dann vom Tool cve-indicator verwendet, um einen Report über die gefundenen bekannten Schwachstellen zu generieren. Somit ist cve-search als Hilfstool zu verstehen.
Da nun alle Scanner Tools festgelegt und Buildbot als Grundsystem ausgewählt wurde, müssen die einzelnen Komponenten zusammengebracht werden.
3.5.3 Zusammenführen der Tools In diesem Abschnitt wird gezeigt, wie die im Abschnitt 3.5.1 gezeigten einzel- nen Konfigurationselemente, Hook, Scheduler, Builder, Buildsteps und Reporter definiert werden müssen, um alle Tools zusammenzuführen und die geforderte Umsetzung von automatisierten, entwicklungsbegleitenden Vulnerability Tests zu realisieren.
52 3 Umsetzung von automatisierten Vulnerability Tests
Für die Verwendung von Buildbot wird keine neue Instanz erstellt. Hier wird der Master eines bereits existierenden Buildbots verwendet, an dem die Elemen- te Worker, Scheduler, Builder etc. angehängt werden. Dieser Master beinhaltet derzeit alle Builds, mit der verschiedene Testgeräte funktional getestet werden. Dieser empfängt vom Buildsystem nach Fertigstellung der Firmwareimages einen Hook, der auch für das Auslösen der automatisierten Vulnerability Tests genutzt werden kann. Durch diese Integration, soll folgender Ablauf implementiert werden.
Sobald das Buildsystem mit dem Build der Firmwareimages fertig ist, soll durch den gesendeten Hook an den Master, in dem die automatisierten Vulnerability Tests integriert werden, einen Scheduler aufgerufen werden, der die Vulnerability Tests anstößt. Dieser soll dann den Builder anstoßen, der daraufhin die einzelnen Schritte zur Überprüfung ausführt. Wie bereits im Abschnitt 3.2.2 erwähnt, sind in diesem Builder Schritte enthalten, die das neu gebaute Image automatisiert auf das Testgerät flashen. Nachdem die Tests beendet sind, sollen die einzelnen Testberichte auf einem FTP-Server abgelegt werden. Die Abbildung 3.11 soll dies nochmal veranschaulichen.
53 3 Umsetzung von automatisierten Vulnerability Tests
Abb. 3.11: Darstellung des zu erstellenden Ablaufs eines automatisierten Vulnerability Tests durch den Zusammenschluss der einzelnen Tools.
Um diesen Ablauf umzusetzen, müssen die Konfigurationselemente Scheduler, Builder und Buildsteps angepasst, beziehungsweise erstellt werden. Da die Konfi- guration der Elemente Hook und Reporter lediglich nur beschreibt, wie die emp- fangenen oder zu sendenden Daten zu filtern sind, wird deren Konfiguration nicht dargestellt.
Im Quelltext 3.12 wird die Konfiguration eines Schedulers gezeigt. Dieser soll nach Empfangen eines Hooks prüfen, ob eine Überprüfung angestoßen werden soll. Es ist anzumerken, dass die Art und Weise der Konfiguration der Program- miersprache Python sehr ähnelt.
54 3 Umsetzung von automatisierten Vulnerability Tests
schedulers_list.append( schedulers.SingleBranchScheduler( name="Scheduler_x86_64", change_filter=util.ChangeFilter( project='LDM', filter_fn=lambda c: c.properties.getProperty('target') == 'x86' and c.properties.getProperty('subtarget') == '64', ), reason="TestingScheduler", builderNames=['APU3_STROMBERG/TDT-LW', 'VULN_TESTER_NG'], properties={ 'url_crossbar': url_crossbar , } ) ) Quelltext 3.12: Konfiguration eines Schedulers, der die Anstoßung eines automatisierten Vulnerability Tests prüft. Durch einen change_filter können die Parameter des Hooks durchsucht wer- den. Hier wird geprüft, ob die fertiggestellten Images für die Architektur x86_64 sind. Ist dies der Fall, wird im speziellen der VULN_TESTER_NG Builder ange- stoßen, der im builderNames definiert ist. Die Konfiguration für die restlichen Architekturen, ist analog zur Konfiguration, die im Quelltext 3.12 gezeigt wird.
Danach können die einzelnen Buildsetps festgelegt werden, die dann dem VULN_- TESTER_NG Builder zugeordnet werden. Der Quelltextausschnitt 3.13 zeigt wie die einzelnen Steps definiert werden, und wie sie Gruppiert werden können. # STEPS FOR VULNERABILITY SCANNING cmd_vuln_image_cpes = steps.SetPropertyFromCommand( name="Get␣cpes␣for␣platform", description="cve-indicator␣gen-list", command=[ "/home/bbworker/.local/share/virtualenvs/cve-indicator -TOE-Wo1O/bin/ ↪ cve-indicator", "gen-list", "openwrt", Interpolate("../../../ binaries/%(prop:path_binaries)s"), ], property="report -gen_list", )
cmd_vuln_image_cves = steps.SetPropertyFromCommand( name="Get␣cves␣for␣platform", description="cve-indicator␣get-cves", command=[ "/home/bbworker/.local/share/virtualenvs/cve-indicator -TOE-Wo1O/bin/ ↪ cve-indicator", "get-cves",
55 3 Umsetzung von automatisierten Vulnerability Tests
Interpolate("%(prop:report -gen_list)s"), ], property="report -get_cves", ) cmd_vuln_gen_report = steps.SetPropertyFromCommand( name="Get␣vuln␣report", description="cve-indicator␣gen-rprt", command=[ "/home/bbworker/.local/share/virtualenvs/cve-indicator -TOE-Wo1O/bin/ ↪ cve-indicator", "gen-rprt", Interpolate("%(prop:report -get_cves)s"), ], property="report -name", ) cmd_vuln_ciphers = steps.ShellCommand( name="Get␣vuln␣ssl␣ciphers", description="nmap␣script", command=[ "nmap", "--script", "ssl-enum -ciphers", "-p", "443", "10.2.30.1", "-oN", "nmap -report.txt", ], ) cmd_vuln_scan_webui = steps.ShellCommand( name="Scan␣WebUI", description="arachni␣scanner", command=[ "python3", "/home/bbworker/arachni_caller.py", ], ) cmd_copy_vuln_test_report = steps.ShellCommand( name="Copy␣test␣report", description="copy_test_report", command=[ "cp", "-r", "/home/bbworker/vuln -worker/VULN -TESTER/vuln -tester/", Interpolate("../../../ binaries/%(prop:path_binaries) ↪ svuln_test_report/"), ], flunkOnFailure=False , )
56 3 Umsetzung von automatisierten Vulnerability Tests
# STEPS COMMON VULN TEST steps_vuln = [ cmd_checkout_tests , cmd_set_path_environment_file , cmd_set_url_image , cmd_set_path_config_file , cmd_aquire_place , cmd_initialize_place , cmd_release_place , cmd_vuln_image_cpes , cmd_vuln_image_cves , cmd_vuln_gen_report , cmd_vuln_ciphers , cmd_vuln_scan_webui , cmd_copy_vuln_test_report , ]
# STEPS SHORT VULN TEST steps_short_vuln = [ cmd_vuln_image_cpes , cmd_vuln_image_cves , cmd_vuln_gen_report , cmd_copy_vuln_test_report , ] Quelltext 3.13: Konfiguration der einzelnen Buildsteps mit anschließender Gruppierung. Für jeden Schritt wird ein Name und eine Beschreibung definiert. Danach folgt unter command der Befehl der ausgeführt werden soll. Falls ein Befehl Werte braucht, die von einem vorherigen Befehl generiert wurden, kann mithilfe der Funktion Interpolate der Wert in einem String eingesetzt werden. Welcher Wert verwendet werden soll, wird durch folgenden Teil angegeben. %(prop:path_binaries)s Dieser Ausdruck wird dann durch den Wert der Variable path_binaries ersetzt. Die einzelnen Steps werden dann in einem Array, beispielsweise dem steps_vuln, in der auszuführenden Reihenfolge zusammengefasst.
Im gezeigten Quelltext 3.13 werden zwei Arrays mit Schritten definiert. Dies ist notwendig, da eine Weboberflächenüberprüfung nur dann vollzogen werden kann, wenn ein für das bereitgestellte Gerät passendes Image gebaut wurde. Dieses ak- tuelle Image wird dann auf das Gerät geflasht, um dieses auf das Vorhandensein von Vulnerabilities prüfen zu können. Dafür werden zusätzliche Schritte benötigt, die im Array steps_vuln enthalten sind. Ist ein Image einer anderen Architektur gebaut worden, kann dies durch die Schritte die im Array steps_short_vuln definiert sind Überprüft werden.
57 3 Umsetzung von automatisierten Vulnerability Tests
Die vorher gruppierten Schritte werden dann den einzelnen BuildFactories zu- geordnet. Danach wird jede Factory den dazugehörigen Builds zugeordnet. Dies zeigt Quelltext 3.14. # COMMON VULN TEST FACTORY f_vuln = factory.BuildFactory() f_vuln.workdir = "labgrid" f_vuln.addSteps(build_steps.steps_short_vuln)
# SHORT VULN TEST FACTORY f_short_vuln = factory.BuildFactory() f_short_vuln.workdir = "labgrid" f_short_vuln.addSteps(build_steps.steps_vuln)
builders.append(BuilderConfig( name="VULN_TESTER_NG", workernames=['vuln -worker'], factory=f_vuln , locks=[build_lock.access('counting')], env={ 'LG_TEST_CROSSBAR': util.Property('url_crossbar'), 'LG_TEST_BOOTTYPE': 'Uboot', 'LG_TEST_URL': util.Property('url'), }, properties={ 'profile': 'APU3_STROMBERG', 'image': 'TDT', 'labgrid_place': 'test_place1' } ) )
builders.append(BuilderConfig( name="SHORT_VULN_TESTER_NG", workernames=['vuln -worker'], factory=f_vuln , locks=[build_lock.access('counting')], ) ) Quelltext 3.14: Konfiguration von BuildFactories und von Buildern. In die Variablen f_fuln und f_short_vuln werden die benötigten BuildFacto- rys gespeichert, die dann bei den einzelnen Buildern unter factory hinzugefügt werden. Unter workernames wird der zuständige Worker angegeben, der selbst nur durch workername und Passwort konfiguriert wird. Zusätzlich können noch benötigte Daten oder Environment Variablen, diese werden über das Betriebssys- tem zur Verfügung gestellt, angegeben werden.
Da alle benötigten Element konfiguriert sind, müssen diese im Buildbot Master aktiviert werden. Dazu sind folgende Befehle nötig.
58 3 Umsetzung von automatisierten Vulnerability Tests
# Prüfen der Konfigurationsdatei auf Fehler buildbot checkconfig
# Aktivieren der geänderten Konfiguration buildbot reconfig Nachdem diese aktiviert sind werden sie für den nächsten startenden Build ange- wendet. Um die Überprüfung anzustoßen muss ein Hook vom Buildsystem nach einen erfolgreichen Build gesendet werden.
Wird eine Überprüfung ausgelöst, werden die definierten Schritte nacheinander Ausgeführt. Abbildung 3.12 zeigt den abgeschlossenen Verlauf eines Vulnerability Tests. Die Schritte 0 bis 6 sind notwendig, um das Testgerät mit der aktuellen Firmware zu bespielen. In den Schritten 7 bis 11 werden die integrierten Tools ausgeführt und die dazugehörigen Berichte erstellt. Diese werden dann im Schritt 12 auf den FTP-Server kopiert. Eine Überprüfung ohne Web-Benutzerschnittstelle beinhaltet nur die Schritte 7,8,9,10 und 12.
59 3 Umsetzung von automatisierten Vulnerability Tests
Abb. 3.12: Anzeige über den Verlauf der einzelnen Buildsteps eines automatisierten Vulnerability Tests.
Die dort liegenden Reports werden dann verwendet, mithilfe der darin ent- haltenen Daten wie CVE, CWE, CPE und CVSS die im Kapitel 2.2 vorgestellt wurden, um die einzelnen Schwachstellen zu verifizieren und zu beheben. Im Ab- schnitt 3.5.2 wurde in Abbildung 3.9 ein Beispielreport von Arachni, in Quelltext 3.6 ein Beispielreport von Nmap und in Abbildung 3.10 ein Beispielreport von cve-indicator gezeigt. Die automatisierten Vulnerability Test werden durch diese Konfiguration nach jedem erfolgreichen Build ausgeführt. Da somit die automa- tisierten Vulnerability Tests von Embeded Devices Umgesetzt wurden, kann eine Fazit gezogen werden.
60 4 Fazit
4 Fazit
Mit dieser Bachelorarbeit sollte überprüft werden, ob automatisierte Vulnerability Tests von Embedded Devices umsetzbar sind. Es wurde geprüft, ob bereits existie- rende Scanner Frameworks wie Nessus oder OpenVas für die Umsetzung verwendet werden können. Diese konnten die gestellten Anforderungen, wie beispielsweise eine minimale Anzahl von bereit zu stellenden Testgeräten, nicht erfüllen. Des Weiteren stellte sich heraus, dass deren eindeutige Zuordnung von Paketnamen und CPE nicht beweisbar/widerlegbar war. Deshalb wurde ein alternatives Test- system mithilfe der Tools Buildbot, Arachni, Nmap, cve-indicator und cve-search entworfen. Diese Tools ermöglichen eine Automatisierung des Scans der Web-Web- benutzerschnittstelle, der Überprüfung der Verschlüsselungsalgorithmen auf Ak- tualität und der Überprüfung von Softwarepaketen auf bekannte Vulnerabilities. Der Zusammenschluss dieser ermöglichte somit eine Umsetzung von automatisier- ten Vulnerability Tests von Embedded Devices. Da dadurch entwicklungsbeglei- tend die Firmware der Router der TDT AG auf bekannte Vulnerabilities getestet werden kann, konnte das Ziel der Bachelorarbeit in diesem Rahmen erfüllt werden.
Anzumerken ist, dass durch dieses Testsystem Vulnerabilities nur identifiziert wer- den können. Eine eindeutige Verifikation des Vorhandenseins der Vulnerabilities auf dem System muss individuell geschehen. Da die Architektur des Testsystems jedoch modular und generisch gehalten wurde, kann eine automatisierte Verifika- tion in Zukunft integriert werden. Des Weiteren kann noch eine Lösung erarbeitet werden, um die einzelnen Berichte der Tools in einem Gesamtbericht zusammen- zuführen. Eine solche Architektur erlaubt es auch, dieses Testsystem an andere Anforderungen anzupassen, wodurch eine Überprüfung von anderen Embedded Devices ermöglicht wird.
Mithilfe des Tools cve-indicator konnte der große Bedarf an Testgeräten wesentlich reduziert werden, da dieses nur Dateien für eine Überprüfung benötigt. Derzeit ist dieses Tool speziell auf Openwrt ausgerichtet. Andere GNU/Linux Distributionen stehen jedoch vor derselben Herausforderung. Deshalb wird das Tool weiterent- wickelt, um es anderen Distributionen ebenfalls zu ermöglichen, ihre verwendeten Pakete auf bekannte Vulnerabilities zu überprüfen.
Abschließend kann gesagt werden, dass durch die stetige Überprüfung der Embed- ded Devices auf bekannte Vulnerabilities und deren Behebung die Sicherheit der Geräte fortlaufend verbessert werden kann. Eine 100%tige Sicherheit kann jedoch
61 4 Fazit niemals erreicht werden. Um jedoch auf den Ernstfall eines Angriffs vorbereitet zu sein, müssen die Router und die Netzwerke, in denen sie zum Einsatz kommen, auf Resilienz untersucht werden.
62 Literatur
Literatur
[1] Arachni. Web User Interface. 5. März 2019. url: https : / / www . arachni - scanner.com/screenshots/web-user-interface/ (besucht am 05. 03. 2019). [2] Buildbot Projekt. Buildbot Basics. 26. Feb. 2019. url: https://buildbot.net/ index.html#basics (besucht am 26. 02. 2019). [3] Buildbot Projekt. Buildbotmaster Architecture. 26. Feb. 2019. url: http : / / docs . buildbot . net / current / manual / introduction . html # buildmaster - architecture (besucht am 26. 02. 2019). [4] CVE Project. DRAFT - CVE ID JSON File Format 4.0. 16. Feb. 2019. url: https://github.com/CVEProject/automation-working-group/blob/master/ cve_json_schema/DRAFT-JSON-file-format-v4.md (besucht am 16. 02. 2019). [5] Prof. Dr. Claudia Eckert. IT-Sicherheit. Oldenbourg Wissenschaftsverlag GmbH, 2014. [6] FIRST. Common Vulnerability Scoring System v3.0: Specification Document. 2018. url: https : / / www . first . org / cvss / specification - document # 2 - Base - Metrics (besucht am 19. 02. 2019). [7] GNU. GNU und die Freie-Software-Bewegung. 16. Feb. 2019. url: https://www. gnu.org/ (besucht am 22. 02. 2019). [8] hauke. Welcome to the OpenWrt Project. 19. Nov. 2018. url: https://openwrt. org/ (besucht am 14. 02. 2019). [9] Peter Marwendel. Eingebettete Systeme. Springer-Verlag, 2007. [10] MITRE Corporation. Common Weakness Enumeration. 3. Apr. 2018. url: https: //cwe.mitre.org/ (besucht am 16. 02. 2019). [11] MITRE Corporation. CVE and NVD Relationship. 30. Jan. 2019. url: https: / / cve . mitre . org / about / cve _ and _ nvd _ relationship . html (besucht am 16. 02. 2019). [12] National Institute of Standards and Technology. Official Common Platform En- umeration (CPE) Dictionary. 11. Jan. 2019. url: https : / / nvd . nist . gov / Products/CPE (besucht am 11. 01. 2019). [13] National Institute of Standards and Technology. Product Identification. 17. Feb. 2019. url: https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7695.pdf (besucht am 17. 02. 2019). [14] National Institute of Standards and Technology. Vulnerability Metrics. 19. Feb. 2019. url: https://nvd.nist.gov/vuln-metrics/cvss# (besucht am 19. 02. 2019).
63 Literatur
[15] TDT AG. Professionelle VPN Router und VPN Gateways - TDT AG Landshut. 5. März 2019. url: https://www.tdt.de/ (besucht am 05. 03. 2019). [16] tmomas. OpenWrt Project: Overview. 3. Dez. 2018. url: https://openwrt.org/ (besucht am 22. 02. 2019). [17] Wikipedia. GitHub — Wikipedia Die freie Enzyklopädie. 2019. url: https://de. wikipedia.org/w/index.php?title=GitHub&oldid=184946013 (besucht am 03. 03. 2019). [18] Wikipedia. Service Pack — Wikipedia Die freie Enzyklopädie. 2018. url: https: //de.wikipedia.org/w/index.php?title=Service_Pack&oldid=183376427 (besucht am 17. 02. 2019).
64 Abbildungsverzeichnis
Abbildungsverzeichnis
1.1 Beispielkonzept, das eine mögliche Verwendung der Geräte und Dienstleistungen zeigt...... 2 2.1 Komponenten einer CVE-ID ...... 8 2.2 Kategorisierung des Schweregrads einer Schwachstelle je nach CVSS Version ...... 12 2.3 Zyklus des automatisierten Pentestings ...... 18 3.1 Vorderseite eines G3000 VPN-Gateways...... 20 3.2 Rückseite eines G3000 VPN-Gateways...... 20 3.3 Board eines VR2020 Routers...... 21 3.4 Darstellung aller Imagesausprägungen zu den einzelnen Architek- turen und Plattformen...... 23 3.5 Resultat eines Nessus Scans auf einem Testrouter...... 31 3.6 Report eines openvas CVE-Scans ...... 32 3.7 Schematischer Aufbau von Buildbot ...... 37 3.8 Schematisches Zusammenspiel der Einzelnen Komponenten . . . . 39 3.9 Beispielausschnitt eines Arachni HTML-Report ...... 43 3.10 Teil eines cve-indicator HTML Reports ...... 50 3.11 Darstellung des zu erstellenden Ablaufs eines automatisierten Vul- nerability Tests durch den Zusammenschluss der einzelnen Tools. 54 3.12 Anzeige über den Verlauf der einzelnen Buildsteps eines automa- tisierten Vulnerability Tests...... 60
65 Quelltextverzeichnis
Quelltextverzeichnis
2.1 JSON-Schema zur Definition eines CVE Eintrags ...... 6 3.1 Eintrag des dropbear Paketes in der Manifestdatei ...... 26 3.2 Beispiel einer Anfrage zum Starten eines Scans, an die REST- Schnittstelle von Arachni ...... 41 3.3 Beispielantwort einer Anfrage bezüglich des Status des Scans . . . 41 3.4 Beispiel einer Anfrage zum download eines Scans, an die REST- Schnittstelle von Arachni ...... 42 3.5 Nmap Befehl mit Parameter für Überprüfung der Ciphersuit auf Aktualität ...... 44 3.6 Ergebnis eines nmap ssl-enum-ciphers Scans ...... 44 3.7 Verzeichnisstruktur für Manifestdateien Architektur x86_64 . . . 46 3.8 JSON Datei, die die Erbenisse des Befehls cve-indicator gen-list enthalten ...... 47 3.9 Daten im JSON-Format, die die Ergebnisse der Ausführung des Befehls cve-indicator get-cves enthalten...... 48 3.10 Beispiel einer API-Anfrage an cve-search, um alle CVEs zu einer gegebenen CPE zu erhalten ...... 52 3.11 Antwortdaten im JSON-Format, erhalten von cve-search nach ei- ner Suche über die API von cve-search...... 52 3.12 Konfiguration eines Schedulers, der die Anstoßung eines automa- tisierten Vulnerability Tests prüft...... 55 3.13 Konfiguration der einzelnen Buildsteps mit anschließender Grup- pierung...... 55 3.14 Konfiguration von BuildFactories und von Buildern...... 58
66 Glossar
Glossar
GitHub ”GitHub ist ein Onlinedienst, der Software-Entwicklungsprojekte auf sei- nen Servern bereitstellt (Filehosting). Namensgebend war das Versionsver- waltungssystem Git. Die GitHub, Inc. hat ihren Sitz in San Francisco in den USA.”[18]. GNU GNU (GNU’s Not Unix) ist ein Betriebssystem, das Freie Software ist ‑ d. h. es respektiert die Freiheit der Nutzer. Das GNU-Betriebssystem besteht aus GNU-Paketen (Programme, die speziell vom GNU-Projekt freigegeben wurden) sowie von Dritten freigegebene Freie Software. Die Entwicklung von GNU ermöglichte es einen Rechner ohne Software benutzen zu können, die Ihre Freiheit mit Füßen treten würde. [7].
Service Pack Service Pack ist ein von verschiedenen Herstellern verwendeter Be- griff für die Zusammenstellung von Patches zur Aktualisierung eines ihrer Betriebssysteme und anderer Software-Produkte [17].
67 Akronyme
Akronyme
AG Aktien Gesellschaft. API Application programming interface.
BSI Bundesamt für Sicherheit in der Informationstechnik.
CPE Common Platform Enumeration. CPU Central Processing Unit. CVE Common Vulnerabilities and Exposures. CVSS Common Vulnerability Scoring System. CWE Common Weakness Enumeration.
DSL Digital Subscriber Line.
FTP File Transfer Protocol.
HTML Hypertext Markup Language. HTTP Hyper Text Transfer Protokoll.
ID Identity. ISO International Standardization Organisazation. IT Informations-Technologie.
JSON JavaScript Object Notation.
LTE Long Term Evolution.
NIST National Institute of Standards and Technology. NVD National Vulnerability Database.
OSI Open System Interconnection.
68 Akronyme
REST Representational State Transfer.
SIM Subscriber Identity Module. SSH Secure Shell. SSL Secure Sockets Layer.
TDT Transfer Data Test. TLS Transport Layer Security.
URI Uniform Resource Identifiers. URL Uniform Resource Locator.
VPN Virtual Private Network.
Wlan Wireless Local Area Network.
69