Sicherheitsanalyse von NoSQL-Datenbanken

Transkript

1 Universität Ulm Fakultät für Ingenieurwissenschaften und Informatik Institut für Verteilte Systeme Bachelorarbeit im Studiengang Informatik Sicherheitsanalyse von NoSQL-Datenbanken Christoph Rothermel vorgelegt am 24. Oktober 2014 Gutachter: Prof. Dr. Frank Kargl Betreuer: Benjamin Erb Rens van der Heijden

2 Fassung vom: 6. Mai 2015 cbnd Diese Arbeit ist lizensiert unter der Creative Commons Namensnennung-Keine kommerzielle Nutzung-Keine Bearbeitung 3.0 Deutschland Lizenz. Nähere Informationen finden Sie unter: oder senden Sie einen Brief an: Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.

3 Zusammenfassung NoSQL-Datenbanken werden immer häufiger produktiv eingesetzt, um die steigenden Datenmengen bewältigen zu können. Derzeit ist allerdings noch nicht klar, ob diese die notwendigen Sicherheitsanforderungen erfüllen. Zu diesem Zweck stellt die vorliegende Arbeit eine Methodik zur Sicherheitsanalyse von NoSQL-Datenbanken vor. Hierzu werden die wichtigsten Sicherheitsrisiken identifiziert und es wird aufgezeigt, wie eine NoSQL-Datenbank auf diese überprüft werden kann. Die Methodik wird auf die NoSQL-Vertreter Neo4j und CouchDB angewendet. Es zeigt sich hierbei, dass beide Datenbanken schwerwiegende Sicherheitsdefizite aufweisen. Deshalb werden Empfehlungen zur Steigerung der Informationssicherheit gegeben, die bei Beachtung die ermittelten Schwachstellen beheben.

4

5 Inhaltsverzeichnis 1 Einleitung Situationsanalyse Problemstellung und Lösungskonzept Aufbau der Arbeit Grundlagen NoSQL-Datenbanken Definition und Abgrenzung Kategorisierung und Anwendungsfälle Charakteristische Eigenschaften Sicherheit in IT-Systemen Definition des Begriffs IT-Sicherheit Definition des Begriffs Sicherheitsanalyse Definition des Begriffs Penetrationstest Zusammenfassung Stand der Forschung Methodologien OWASP Testing Guide Open Source Security Testing Methodology Manual (OSSTMM) Information Systems Security Assessment Framework (ISSAF) Anwendbarkeit auf NoSQL-Datenbanken Sicherheit von Datenbanken Sicherheit von relationalen Datenbanken Sicherheit von NoSQL-Datenbanken Vergleich der Sicherheit von relationalen- und NoSQL-Datenbanken Schlussfolgerungen Sicherheitsrisiken von NoSQL-Datenbanken Schwache Konfiguration Unzureichende Datenvalidierung Fehlende oder schwache Kryptographie Zusammenfassung

6 Inhaltsverzeichnis 5 Methodik zur Sicherheitsanalyse von NoSQL-Datenbanken Informationsbeschaffung Konfiguration Datenvalidierung Kryptographie Testphase Testen der Konfiguration Testen der Datenvalidierung Testen der Kryptographie Risikobewertung Risikoidentifizierung Faktoren zur Bestimmung der Eintrittswahrscheinlichkeit Faktoren zur Bestimmung der Auswirkung Ermitteln des Ausmaßes des Risikos Welche Schwachstelle soll behoben werden? Zusammenfassung Validierung am Beispiel der NoSQL-Datenbank Neo4j Einführung in Neo4j Einordnung und Charakterisierung Testaufbau Beispielabfragen Sicherheitsanalyse von Neo4j Informationsbeschaffung Testphase Risikobewertung Ergebnisse der Sicherheitsanalyse von Neo4j Validierung am Beispiel der NoSQL-Datenbank CouchDB Einführung in CouchDB Einordnung und Charakterisierung Testaufbau Beispielabfragen Sicherheitsanalyse von CouchDB Informationsbeschaffung Testphase Risikobewertung Ergebnisse der Sicherheitsanalyse von CouchDB Empfehlungen zur Steigerung der Informationssicherheit Fehlende Sicherheitsmechanismen implementieren Wizard zur Konfiguration der NoSQL-Datenbank Schutzmechanismen gegen Angriffe auf die Datenvalidierung vi

7 Inhaltsverzeichnis 8.4 Schlussfolgerungen Resümee und Ausblick Resümee Ausblick Anhang A Materialien zur Validierung von Neo4j 103 A.1 Neo4j PHP-Applikationen A.1.1 Personensuche Programmcode-Auszug A.1.2 Traversierung Programmcode-Auszug A.2 Neo4j Javascript Injection A.2.1 Javascript-DOS-Injection Testwebsite-Auszug A.2.2 Javascript-DOS-Injection Testjson Anhang B Materialien zur Validierung von CouchDB 107 B.1 CouchDB PHP-Applikationen B.1.1 Personensuche Programmcode-Auszug B.1.2 Personenregistrierung Programmcode-Auszug vii

8

9 1 Einleitung 1.1 Situationsanalyse Die zu speichernde und zu übertragende Datenmenge nimmt stetig zu. Internet-Giganten wie Facebook und Google müssen beispielsweise täglich mehrere Milliarden Datenanfragen ohne große Verzögerungen verarbeiten [25]. Ansteigende Benutzerzahlen wurden noch vor wenigen Jahren ausschließlich durch das Aufrüsten der Serverhardware (vertikale Skalierung) bewältigt. Im derzeitigen Web 2.0 ist dies nicht mehr ausreichend. Internetkonzerne setzen immer mehr auf horizontale Skalierung: Die Anfragen werden auf mehrere Server verteilt. Hierbei stoßen allerdings sehr viele Systeme an ihre Grenzen: Die meisten herkömmlichen relationalen Datenbanken können nur vertikal skalieren. Populäre Datenbankvertreter lassen zwar oft eine horizontale Skalierung zu, diese ist aber mit sehr vielen Restriktionen (z.b. keine Join-Operationen) verbunden [15]. Diese mangelnde Skalierbarkeit von relationalen Datenbanken ist eines der Hauptgründe für den starken Popularitätszuwachs von NoSQL-Datenbanken in den vergangenen Jahren. Diese haben das primäre Ziel, eine einfach zu konfigurierende Skalierung zu gewährleisten. Um dies zu realisieren, werden im Vergleich zum relationalen Modell grundlegend verschiedene Datenmodelle verwendet, die noch viele weitere Besonderheiten, wie z.b. eine Schemafreiheit, anbieten. Das macht NoSQL-Systeme sehr attraktiv für große Webanwendungen [9]. NoSQL-Datenbanken werden bereits verwendet, um Daten zu speichern. Dies können zum einen für die Öffentlichkeit bestimmte Informationen sein, zum anderen aber auch vertrauliche bzw. geheime Daten. Im Gegensatz zu den populären relationalen Datenbanken, die schon sehr lange eingesetzt werden und etlichen Sicherheitsanalysen unterzogen wurden, existieren derartige Erfahrungswerte bzw. Evaluierungen für NoSQL-Datenbanken nur bedingt oder sind veraltet. Es ist also zu überprüfen, ob die NoSQL-Vertreter die Informationssicherheit mit ihren drei klassischen Zielen Vertraulichkeit, Integrität und Verfügbarkeit gewährleisten. Die vorliegende Arbeit leistet hierzu einen Beitrag, indem sie eine Methodik zur Sicherheitsanalyse von NoSQL-Datenbanken definiert, mit der NoSQL-Vertreter effizient auf die kritischsten Sicherheitsrisiken überprüft werden können.

10 1 Einleitung 1.2 Problemstellung und Lösungskonzept Wie in Kapitel 1.1 dargestellt wurde, steigt die Zahl der Anwender von NoSQL-Datenbanken rasant an, da für das Web 2.0 herkömmliche relationale Datenbanken nicht mehr ausreichen. Diese zunehmende Beliebtheit macht NoSQL-Datenbanken aber auch immer attraktiver für Personen, die in diese Systeme eindringen wollen. Das Ziel solcher Attacken sind in den meisten Fällen die gespeicherten Daten, wie zum Beispiel Benutzerdaten oder Kreditkartendaten. Da NoSQL-Datenbanken unter anderem auch für sensible Daten verwendet werden, sind entsprechende Sicherheitsvorkehrungen notwendig. Ein Blick auf den Stand der Forschung in Kapitel 3 zeigt, dass es zur Sicherheit von NoSQL-Datenbanken derzeit nur sehr wenige bzw. gar keine wissenschaftlichen Arbeiten gibt. Daraus ergibt sich die Problemstellung dieser Arbeit: Es ist zu überprüfen, wie fortgeschritten die Sicherheit von NoSQL-Datenbanken ist. Zur Lösung dieser Problemstellung, werden in einem ersten Schritt die bedeutendsten Sicherheitsrisiken von NoSQL-Systemen ermittelt. In einem zweiten Schritt wird eine generische Methodik zur Sicherheitsanalyse erforscht, welche eine effiziente Einschätzung der Sicherheit von NoSQL-Datenbanken ermöglichen soll. Zur Validierung dieser Vorgehensweise wird die Methodik auf die NoSQL-Vertreter Neo4j und CouchDB angewendet. Mit den Ergebnissen dieser Anwendungen werden anschließend generelle Empfehlungen zur Steigerung der Informationssicherheit erarbeitet. 1.3 Aufbau der Arbeit Diese Arbeit beginnt mit den Grundlagen zu NoSQL-Datenbanken und der IT-Sicherheit in Kapitel 2. Anschließend wird in Kapitel 3 ein Blick auf bestehende Methoden zur Sicherheitsanalyse sowie den derzeitigen Forschungsstand der Sicherheit von relationalen und NoSQL-Datenbanken geworfen. In einem nächsten Schritt werden in Kapitel 4 die wichtigsten Sicherheitsrisiken von NoSQL-Datenbanken vorgestellt. Diese werden von der Methodik zur Sicherheitsanalyse in Kapitel 5 wieder aufgegriffen, in dem gezeigt wird, wie NoSQL-Systeme entsprechend dieser Risiken analysiert werden können. Es folgt in Kapitel 6 eine Validierung der Methodik anhand der NoSQL-Datenbank Neo4j und in Kapitel 7 anhand des NoSQL-Vertreters CouchDB. Aufbauend auf den Erkenntnissen der Validierungen werden in Kapitel 8 generelle Empfehlungen zur Steigerung der Informationssicherheit gegeben. In Kapitel 9 wird abschließend eine Zusammenfassung der Inhalte dieser Arbeit vorgestellt und ein kurzer Ausblick aufgezeigt. 2

11 2 Grundlagen In diesem Kapitel werden essentielle Konzepte aus dem Gebiet NoSQL-Datenbanken sowie aus der IT-Sicherheit vorgestellt. Die eingeführten Begriffe und Definitionen dienen dem Verständnis der späteren Sicherheitsanalyse von NoSQL-Datenbanken. 2.1 NoSQL-Datenbanken In dem derzeitigen Internet-Zeitalter setzen immer mehr führende Unternehmen auf NoSQL-Systeme, um die steigende Anzahl an Internetzugriffen bewältigen zu können. Mittlerweile ist diese Datenbankkategorie somit nicht mehr wegzudenken. Um die Hintergründe von NoSQL-Datenbanken zu verstehen, wird in diesem Abschnitt der Begriff NoSQL-Datenbank definiert und von relationalen Datenbanken abgegrenzt. Anschließend wird aufgezeigt, wie die Vertreter dieser neuen Datenbanksparte kategorisiert werden können und welche Anwendungsfälle es für diese gibt. Abschließend werden charakteristische Eigenschaften von NoSQL-Datenbanken vorgestellt, die es ermöglichen sollen, einzelne Datenbanken voneinander abgrenzen zu können Definition und Abgrenzung Hört man erstmals den Begriff NoSQL-Datenbanken denkt man zwangsläufig, dass diese kein SQL als Abfragesprache verwenden. Dies stimmt zwar teilweise, aber ist nicht ausreichend, um NoSQL-Systeme zu definieren. Die Internetseite nosql-database.org 1, welche sich mit der Definition und Aufzählung der Vertreter dieser Datenbanksparte befasst, empfiehlt deshalb, NoSQL als not only SQL (auf Deutsch nicht nur SQL) aufzufassen. Eine Besonderheit dieser neuen Datenbanken ist, dass es hierfür keine exakte Definition gibt, weshalb viele Entwickler und Forscher den Begriff NoSQL unterschiedlich auslegen. In der Literatur wird deshalb oft eine Liste an Charakteristika angegeben, um diesen Begriff zu definieren. NoSQL-Datenbanken können wie folgt definiert werden [9, S. 2ff.]: Definition 2.1 (NoSQL). Unter NoSQL wird eine neue Generation von Datenbanksystemen verstanden, die meistens einige der nachfolgenden Punkte berücksichtigen: 1. Das zugrundeliegende Datenmodell ist nicht relational. 1 zuletzt abgerufen am

12 2 Grundlagen 2. Die Systeme sind von Anbeginn an auf eine verteilte und horizontale Skalierbarkeit ausgerichtet. 3. Das NoSQL-System ist Open Source. 4. Das System ist schemafrei oder hat nur schwächere Schemarestriktionen. 5. Aufgrund der verteilten Architektur unterstützt das System eine einfache Datenreplikation. 6. Das System bietet eine einfache API. 7. Dem System liegt meistens auch ein anderes Konsistenzmodell zugrunde: Eventually Consistent und BASE, aber nicht ACID. Zusätzlich zu erwähnen ist, dass das Primärziel von NoSQL eine sehr gute Skalierbarkeit darstellt, um die sehr großen Datenmengen des Web 2.0-Zeitalters verarbeiten zu können, die im Terabyte- oder sogar Petabyte-Bereich liegen können. Es soll eine einfach zu konfigurierende horizontale Skalierbarkeit gewährleistet werden. Hierbei wird die Leistung der Datenbank durch das Hinzufügen zusätzlicher Knoten gesteigert. Relationale Datenbanken können meist nur durch vertikale Skalierung, also durch Aufrüstung der Serverhardware, beschleunigt werden [9]. Ein weiterer grundlegender Unterschied von NoSQL-Datenbanken im Vergleich zu relationalen Datenbanken ist, dass diese meist schemafrei sind oder nur schwächere Schemarestriktionen besitzen. Ein Hinzufügen von neuen Attributen in der Datenbank oder in einzelnen Datensätzen ist somit sehr einfach möglich [9]. NoSQL-Systeme bieten außerdem die Möglichkeit einer Datenreplikation an. Hierbei wird eine Kopie der Daten auf mehreren Servern gespeichert, die meist auf viele Standorte verteilt sind. Die Daten werden durch Synchronisation zwischen den Rechnern aktuell gehalten. Viele relationale Datenbanken bieten auch eine Datenreplikation an, diese ist allerdings aufgrund des hohen Verwaltungsaufwandes sehr inperformant. Des Weiteren wird von einigen NoSQL-Vertretern das sogenannte Sharding unterstützt. Hierbei werden die Daten auf viele Server verteilt, um die Performance zu erhöhen. Eine Kombination von Sharding und Datenreplikation ist möglich [9]. Im Gegensatz zu relationalen Datenbanken verwenden NoSQL-Systeme meist kein SQL bzw. eine einheitliche Abfragesprache. Einige NoSQL-Vertreter bieten speziell angepasste Abfragesprachen, wie z.b. Cypher bei Neo4j, an oder unterstützen Map/Reduce- Abfragen, welche sich besonders bei verteilten Systemen anbieten. Der Datenbankzugriff erfolgt durch eine zur Verfügung gestellte API oder durch eine REST-Schnittstelle [9]. NoSQL-Datenbanken bieten außerdem im Vergleich zu relationalen Systemen ein weiteres Konsistenzmodell mit dem Namen BASE (Basically Available, Soft State, Eventual Consistent) an. Unter Konsistenz bei der Datenspeicherung wird allgemein die Korrektheit der in der Datenbank zu speichernden Daten verstanden [30]. Insbesondere bei einer verteilten Datenbank ist die Wahrung der Konsistenz kein einfaches Unterfangen: Die Instanzen müssen sich synchronisieren, damit diese beispiels- 4

13 2.1 NoSQL-Datenbanken weise nach einem Änderungsauftrag auf dem gleichen Stand sind. Zur Lösung dieses Problems gibt es viele Ansätze: Während relationale Systeme auf das transaktionsbasierte Konzept ACID (Atomicity, Consistency, Isolation, Durability) setzen, gehen die meisten NoSQL-Datenbanken mit BASE einen anderen Weg: Sie argumentieren, dass nicht alle Internetanwendungen strikte Konsistenz- und Transaktionsanforderungen benötigen. Anstatt Konsistenz zu garantieren, bieten sie im Gegenzug geringere Latenzen an und können somit mehrere Anfragen bearbeiten. Datenbanken, die für einen kurzen Zeitraum (zum Beispiel nach einem Schreibvorgang) inkonsistente Daten enthalten, aber nach kurzer Zeit konsistent werden, werden als Eventually Consistent bezeichnet. Diese Systeme benötigen keine ACID-Garantien und bieten deshalb keine Transaktionen an [9] Kategorisierung und Anwendungsfälle Derzeit gibt es über 150 NoSQL-Systeme 2, das Spektrum reicht von exotischen bis hin zu bereits etablierten Datenbankvertretern, wie MongoDB oder Cassandra. Aufgrund dieser Vielzahl an Systemen hat man diverse Kategorien erstellt, in die man jeden NoSQL-Vertreter einordnen kann: Wie in Abbildung 2.1 zu sehen ist, kann man NoSQL- Datenbanken grob in Kern-NoSQL-Systeme (Core) und nachgelagerte (Soft-)NoSQL- Systeme einteilen. Diese können wie folgt wiederum in Untergruppen aufgeteilt werden [9]: NoSQL-Kernsysteme: Key/Value/Tuple Stores Document Stores Wide Column Stores/Column Families Graphdatenbanken Nachgelagerte NoSQL-Systeme: Objektdatenbanken XML-Datenbanken Grid-Datenbanken... Um einen Eindruck von den wichtigsten NoSQL-Kategorien zu bekommen, sollen diese nun kurz vorgestellt und mit Anwendungsbeispielen versehen werden. Key/Value-Stores Eine Key/Value-Datenbank ist eine einfache Hashtabelle, welche den Zugriff auf die gespeicherten Daten mithilfe eines Primärschlüssels ermöglicht [10]. Diese kann man 2 zuletzt abgerufen am

14 2 Grundlagen Grid-Datenbanken Soft XML-Datenbanken Key/Value/Tupe Stores Column Families Core Document Stores Graphdatenbanken Objektdatenbanken Cloud-Datenbanken Multidimensionale-Datenbanken Abbildung 2.1: Kategorisierung von NoSQL-Datenbanken sich als eine Tabelle mit den Spalten KEY und VALUE vorstellen. Die KEY-Spalte enthält die Schlüssel (Keys) und die VALUE-Spalte enthält die zu speichernden Werte (Values) in Form von Zeichenketten. Es kann nur über den Key auf die Daten zugegriffen werden [10]. Ein Vorteil dieses Konzepts ist, dass die Daten aufgrund des einfachen Datenmodells sehr schnell und effizient verwaltet sowie verteilt werden können. Ein großer Nachteil ist beispielsweise, dass je nach Mächtigkeit der API keine komplexen Abfragen verfasst werden können [9]. Key/Value-Systeme eignen sich besonders gut für Systeme, die großen Wert auf die Verfügbarkeit legen. Folgende Anwendungsfälle für diese Datenbanken sind denkbar [12]: Sessionspeicher Benutzerdatenspeicher Speicher für Cloud-Infrastrukturen Populäre Vertreter dieser Kategorie sind beispielsweise DynamoDB von Amazon, sowie Riak und Redis. 6

15 2.1 NoSQL-Datenbanken Document Stores In Dokumentendatenbanken werden strukturierte Datensammlungen wie JSON-, XMLoder BSON-Dokumente zusammen mit einer ID gespeichert [10]. Document Stores haben eine ähnliche Datenstruktur wie Key/Value-Systeme, wobei die Values die Dokumente darstellen. Diese Datenbankkategorie bietet im Gegensatz zu Key/Value-Datenbanken zusätzlich die Möglichkeit an, den Value (also die Dokumente) bei einer Abfrage zu durchsuchen [10, 9]. Positiv an diesem Ansatz ist, dass beliebige Daten bzw. Dokumente in den Datenbanken gespeichert werden können. Im Gegensatz zu relationalen Datenbanken kann hier in einem Feld eine Liste an Daten gespeichert werden. Bei relationalen Datenbanken benötigt man dafür mehrere Relationen. Dies birgt allerdings auch Nachteile: Beispielsweise muss aufgrund der schwachen Struktur oft auf viele komfortable Funktionen, wie selbstdefinierte Constraints und Trigger, verzichtet werden [12]. Dokumentendatenbanken eignen sich beispielsweise für folgende Anwendungsfälle [10]: Event Logging Content Management Systeme Zu dieser Kategorie zählen zum Beispiel die Datenbanken MongoDB und CouchDB [8]. Column Families Neben Dokument- und Key/Value-Datenbanken speichern auch Column-Family-Systeme die Daten als Key/Value-Paar ab [10]. Jedem Schlüssel (Key) wird hier eine Menge an Spalten (Values) zugewiesen. Eine Spalte umfasst einen Spaltennamen, einen Wert und meist einen Zeitstempel. Vergleicht man dieses Konzept mit einer Tabelle, wären die Zeilen die Key/Value-Paare und die gesamte Tabelle die Column-Family [28]. Des Weiteren kann zwischen zwei Column-Family-Typen differenziert werden: Es gibt sowohl Standard-Column-Families, welche eine Menge an Spalten enthalten, als auch Super-Column-Families, die sogenannte Super-Columns enthalten. Eine Super-Column fasst mehrere Spalten zusammen [28]. Ein Vorteil dieser Kategorie ist, dass sehr viele Datenstrukturen, wie z.b. auch Listen, gespeichert werden können. Außerdem sind Column Families sehr skalierbar und können deshalb mit großen Datenmengen umgehen. Column-Families eignen sich allerdings nicht für Abfragen, die Daten aggregieren, wie zum Beispiel SUM oder AVG aus SQL [12]. Diese Datenbankkategorie wird meist bei analytischen Informationssystemen eingesetzt, die die Eingabedaten sofort bearbeiten müssen. Dies spiegelt sich auch in der folgenden Liste möglicher Anwendungsfälle wider [10]: 7

16 2 Grundlagen Event Logging Content Management Systeme Besucherzähler (vgl. Cassandra) Ablaufende Daten (vgl. Cassandra) Typische Vertreter dieser Kategorie sind HBase, Cassandra und Hypertable [8]. Graphdatenbanken Graphdatenbanken ermöglichen es Graph- und Baumstrukturen abzubilden und zu verwalten. Die Datenstruktur dieser Kategorie ist vergleichbar mit dem Aufbau des Entity-Relationship-Modells [10]: Es gibt hier Knoten (Entitäten), welche mithilfe von Kanten (Relationen) assoziiert werden können. Diese können meist mit beliebig vielen Attributen versehen werden. Außerdem ist es möglich den Kanten eine Richtung zuzuweisen [10]. Der entscheidende Vorteil dieser Systeme ist, dass Graphalgorithmen ausgeführt werden können, um zum Beispiel den kürzesten Pfad zwischen zwei Knoten zu finden. Ein Nachteil ist, dass das Aktualisieren von mehreren Knoten aufgrund der Graphstruktur eine sehr aufwändige Operation darstellt [12]. Graphdatenbanken eignen sich besonders für folgende Anwendungsfälle [12]: Applikationen mit verbundenen Daten Location Based Services Empfehlungssysteme Die populärste Graphdatenbank ist derzeit Neo4j. Erwähnenswert sind außerdem die Systeme Infinite Graph und DEX [8] Charakteristische Eigenschaften In dem vorherigen Abschnitt wurde bereits gezeigt, dass sich NoSQL-Systeme kategorisieren lassen. Trotz dieser Grobgliederung unterscheiden sich die Datenbankvertreter der jeweiligen Kategorien zum Teil sehr stark. Deshalb sollen in diesem Abschnitt charakteristische Eigenschaften von NoSQL-Datenbanken vorgestellt werden, die es ermöglichen sollen, diese voneinander abzugrenzen (siehe Kapitel und 7.1.1). Konsistenz Im Gegensatz zu relationalen Datenbanken, die eine sehr starke Konsistenz garantieren, kann es bei NoSQL-System durchaus vorkommen, dass unter bestimmten Bedingungen nicht konsistente Daten vorliegen [10]. 8

17 2.1 NoSQL-Datenbanken Zur Konsistenz können folgende Fragen gestellt werden: 1. Welches Konsistenzmodell (z.b. ACID oder BASE) wird verwendet? 2. Wie werden die Daten konsistent gehalten, wenn nur ein Server verwendet wird? 3. Wie werden die Daten konsistent gehalten, wenn diese auf viele Server verteilt sind? Transaktionen Zur Wahrung der Datenkonsistenz fassen relationale Datenbanken mehrere Lese- bzw. Schreibanfragen zu einer Transaktion zusammen, um Konflikte zu erkennen. Diese können durch das Rückgängigmachen der gesamten Transaktion oder durch manuelle Problemlösung korrigiert werden. Die meisten NoSQL-Datenbanken verwenden allerdings nicht dieses strikte Transaktionsmodell, da dies bei einem verteilten System zu starken Latenzeinbußen führt [10]. Zu den Transaktionen ist folgende Frage relevant: 1. Werden Transaktionen bzw. transaktionsähnliche Mechanismen angeboten? Verfügbarkeit Eine der wichtigsten Anforderungen an Datenbanken ist eine sehr hohe Verfügbarkeit. Diese kann beispielsweise durch die Verteilung der Daten auf viele Systeme sichergestellt werden. Hierfür gibt es zwei Möglichkeiten: Replikation und Sharding. Bei der Replikation wird eine Kopie der Daten auf einem weiteren Server erstellt. Beim Sharding enthält jedes System einen anderen Teil der Daten. Beide Möglichkeiten können auch kombiniert werden [10]. Zur Verfügbarkeit können folgende Fragen gestellt werden: 1. Bietet die Datenbank Replikation an? 2. Wird Sharding unterstützt? Abfragemöglichkeiten Während alle relationalen Datenbanken die Abfragesprache SQL unterstützen, gibt es bei NoSQL-Systemen keine einheitliche Möglichkeit, um Datenanfragen zu stellen. Viele NoSQL-Vertreter haben deshalb eigene Abfragesprachen entwickelt, um Anfragen an die Datenbank stellen zu können. Außerdem wird oft auch das Map/Reduce-Konzept unterstützt, um die gewünschten Daten zu erhalten. Wie in Kapitel 7 zu sehen ist, verwendet beispielsweise auch CouchDB Map/Reduce-Abfragen (siehe Kapitel 7.1) [10]. Zu den Abfragemöglichkeiten sind folgende Fragen relevant: 9

18 2 Grundlagen 1. Werden von der Datenbank Abfragesprachen angeboten? Wenn ja, wie mächtig sind diese? 2. Wie können Indizes erstellt werden? 3. Wie können Abfragen ausgeführt werden und welche Konzepte werden hierfür verwendet? Skalierung Wie bereits in Kapitel gesagt wurde, ist das Hauptziel von NoSQL-Datenbanken zu skalieren. Die meisten NoSQL-Systeme realisieren dies durch Sharding, also durch das Verteilen der Daten auf viele Server, oder durch Replikation (=komplette Kopie) der Daten. Eine Kombination dieser beiden Konzepte ist ebenfalls möglich. Eine weitere Möglichkeit zu skalieren ist alle Daten im Arbeitsspeicher zu behalten, was zu einer höheren Performance führt [10]. Folgende Fragen sind bezüglich der Skalierung zu beantworten: 1. Welche Möglichkeiten zur Skalierung werden angeboten? 2.2 Sicherheit in IT-Systemen Zum Verständnis dieser Arbeit ist es erforderlich, die Begriffe IT-Sicherheit, Sicherheitsanalyse und Penetrationstest zu verstehen. Deshalb sollen diese in den folgenden Abschnitten erläutert werden Definition des Begriffs IT-Sicherheit Das Bundesamt für Sicherheit in der Informationstechnik definiert den Begriff IT- Sicherheit wie folgt [5]: Definition 2.2 (IT-Sicherheit). IT-Sicherheit bezeichnet einen Zustand, in dem die Risiken, die beim Einsatz von Informationstechnik (IT) aufgrund von Bedrohungen und Schwachstellen vorhanden sind, durch angemessene Maßnahmen auf ein tragbares Maß reduziert sind. IT-Sicherheit ist also der Zustand, in dem Vertraulichkeit, Integrität und Verfügbarkeit von Informationen und Informationstechnik durch angemessene Maßnahmen geschützt sind. Diese Definition bedarf allerdings noch einiger Erläuterungen: Mit Informationstechnik werden alle technischen Mittel, die zur Verarbeitung und Übertragung von Informationen eingesetzt werden, bezeichnet. In der Begriffserklärung werden außerdem die Begriffe Vertraulichkeit, Verfügbarkeit und Integrität erwähnt. Diese stellen die Grundwerte der IT-Sicherheit und die zu schützenden Ziele dar [5]. Vertraulichkeit kann wie folgt definiert werden [5]: 10

19 2.2 Sicherheit in IT-Systemen Definition 2.3 (Vertraulichkeit). Vertraulichkeit ist der Schutz vor unbefugter Preisgabe von Informationen. Vertrauliche Daten und Informationen dürfen ausschließlich Befugten in der zulässigen Weise zugänglich sein. Mindestens genauso wichtig wie die Vertraulichkeit ist die Verfügbarkeit [5]: Definition 2.4 (Verfügbarkeit). Die Verfügbarkeit von Dienstleistungen, Funktionen eines IT-Systems, IT-Anwendungen oder IT-Netzen oder auch von Informationen ist vorhanden, wenn diese von den Anwendern stets wie vorgesehen genutzt werden können. Das dritte Ziel der IT-Sicherheit ist die Integrität. Das BSI liefert für diesen Begriff folgende Definition [5]: Definition 2.5 (Integrität). Integrität bezeichnet die Sicherstellung der Korrektheit (Unversehrtheit) von Daten und der korrekten Funktionsweise von Systemen. Wenn der Begriff Integrität auf "Datenängewendet wird, drückt er aus, dass die Daten vollständig und unverändert sind. In der Informationstechnik wird er in der Regel aber weiter gefasst und auf Ïnformationenängewendet. Der Begriff Ïnformation"wird dabei für "Daten"verwendet, denen je nach Zusammenhang bestimmte Attribute wie z. B. Autor oder Zeitpunkt der Erstellung zugeordnet werden können. Der Verlust der Integrität von Informationen kann daher bedeuten, dass diese unerlaubt verändert, Angaben zum Autor verfälscht oder Zeitangaben zur Erstellung manipuliert wurden Definition des Begriffs Sicherheitsanalyse Im Titel dieser Arbeit steckt außerdem der Begriff Sicherheitsanalyse, dieser kann wie folgt definiert werden [6]: Definition 2.6 (Sicherheitsanalyse). Unter der Sicherheitsanalyse eines sicherheitskritischen Systems versteht man eine systematische, nachvollziehbare Überprüfung des implementierten Systems hinsichtlich definierter Sicherheitsanforderungen. Die primäre Motivation jeglicher Sicherheitsanalysen besteht darin, potenzielle Gefahrenquellen, die eine korrekte Funktionsweise behindern, zu identifizieren und zu gewichten. Um eine Sicherheitsanalyse durchführen zu können, müssen also in einem ersten Schritt Sicherheitsanforderungen (siehe Kapitel 4) an das System definiert werden. Das System soll anschließend anhand der definierten Anforderungen überprüft werden, wobei potentielle Gefahrenquellen aufgedeckt und bewertet werden sollen (siehe Kapitel 6 und 7). Das genaue Vorgehen bei einer IT-Sicherheitsanalyse ist allerdings nur wenig bis überhaupt nicht spezifiziert. Trotzdem ist in Teilbereichen versucht worden, das Vorgehen zu standardisieren (siehe ISO 27002). 11

20 2 Grundlagen Zur Sicherheitsanalyse von IT-Systemen können sowohl technische Verfahren, wie zum Beispiel Penetrationstests (siehe Kapitel 2.2.3), als auch prozessorierentierte Verfahren eingesetzt werden. Es gibt viele Gründe eine Sicherheitsanalyse bei einem System durchzuführen. Der Hauptgrund hierfür ist sicherlich, dass durch eine derartige Analyse Sicherheitsdefizite aufgedeckt werden können, die ohne eine systematische Überprüfung wahrscheinlich nie aufgefallen wären. Ein weiterer Grund für eine Sicherheitsanalyse ist, dass nach der gleichen Methodik auch potentielle Angreifer vorgehen. Für diese ist es nach einer Überprüfung des Systems nicht mehr so einfach, in dieses einzudringen. Nicht zu vernachlässigen ist außerdem, dass eine durchgeführte Sicherheitsanalyse dem Administrator bzw. den Betreibern des geprüften Systems eine gewisse Sicherheit gibt, dass dieses gegen mögliche Gefahren abgesichert ist bzw. welche Sicherheitsdefizite noch gelöst werden müssen. Diese Liste an Gründe für eine Sicherheitsanalyse zeigt sehr schön, dass die hierfür aufgebrachte Zeit auf keinen Fall umsonst ist. Deshalb ist es sehr zu empfehlen eine derartige Überprüfung unabhängig von der Art der (Web-)Applikation durchzuführen Definition des Begriffs Penetrationstest Die Sicherheit von NoSQL-Datenbanken wird in dieser Arbeit mithilfe einer speziell angepassten Penetrationstestmethodik (siehe Kapitel 5) analysiert. Deshalb ist es wichtig den Begriff Penetrationstest eindeutig zu definieren [5]: Definition 2.7 (Penetrationstest). Ein Penetrationstest ist ein gezielter, in der Regel simulierter, Angriffsversuch auf ein IT-System. Er wird als Wirksamkeitsprüfung vorhandener Sicherheitsmaßnahmen eingesetzt. In der Literatur finden sich bereits sehr viele standardisierte Methoden zum Penetrationstesten. Diese werden in Kapitel 3.1 näher vorgestellt. 2.3 Zusammenfassung In diesem Kapitel wurden die für diese Arbeit notwendigen Grundlagen erläutert. Es wurde festgestellt, dass es keine eindeutige Definition zu dem Begriff NoSQL-Datenbank gibt. Stattdessen existiert eine Liste an Merkmalen, von der zumindest einige Punkte bei jedem NoSQL-Vertreter zutreffen sollten. NoSQL-Systeme lassen sich zudem in Kategorien einteilen. Grob lassen sich diese in NoSQL-Kernsysteme und nachgelagerte NoSQL-Systeme gliedern. Zu den Kernsystemen zählen Key/Value/Tuple Stores, Document Stores, Wide Column Stores/Column Families und Graphdatenbanken. Da sich die Vertreter dieser Kategorien auf den ersten Blick sehr ähneln, wurden anschließend charakteristische 12

21 2.3 Zusammenfassung Eigenschaften definiert, die es erlauben NoSQL-Datenbanken voneinander abzugrenzen. Zu diesen zählen Konsistenz, Transaktionen, Verfügbarkeit, Abfragemöglichkeiten und Skalierung. Im zweiten Teil dieses Kapitels wurden die für diese Arbeit relevanten Grundlagen der IT-Sicherheit vorgestellt. In einem ersten Schritt wurde der Begriff IT-Sicherheit mit dessen Hauptzielen Vertraulichkeit, Verfügbarkeit und Integrität definiert. In einem zweiten Schritt wurde auf den Begriff Sicherheitsanalyse eingegangen und gezeigt, wie sich dieser in der vorliegenden Arbeit widerspiegelt. Abschließend wurde erläutert, was unter einem Penetrationtest zu verstehen ist. Ein derartiger Test ist meist ein elementarer Bestandteil einer Sicherheitsanalyse. 13

22

23 3 Stand der Forschung Es gibt zahlreiche Methoden zum Penetrationstesten von Webapplikationen, welche in diesem Kapitel vorgestellt und auf Anwendbarkeit im NoSQL-Bereich überprüft werden sollen. Anschließend wird der Stand der Forschung im Bereich der Sicherheit von Datenbanken aufgezeigt. 3.1 Methodologien Die populärsten Vorgehensweisen zum Penetrationstesten von Webapplikationen findet man in folgenden Projekten/Handbüchern: OWASP Testing Guide [21], Open Source Security Testing Methodology Manual [14] und Information Systems Security Assessment Framework [18]. Diese werden in diesem Abschnitt kurz vorgestellt und auf Anwendbarkeit im NoSQL-Bereich überprüft OWASP Testing Guide Das Open Web Application Security Project (OWASP) ist eine Non-Profit-Organisation, die sich aus Firmen, Bildungseinrichtungen und Einzelpersonen zusammensetzt. OWASP hat das Ziel, die Sicherheit von Internetanwendungen sowie Diensten zu verbessern. Hierfür wird eine Vielzahl an Projekten angeboten, wie beispielsweise der Testing Guide. Dieser beschreibt, wie eine Webapplikation während des gesamten Software Development Lifecycles auf Sicherheitsaspekte überprüft werden kann. Der Schwerpunkt dieses Handbuchs liegt auf der Vorgehensweise beim Penetrationstesten von Internetanwendungen, wobei ausführlich beschrieben wird, was und in welcher Reihenfolge getestet werden sollte [21]. Der OWASP Testing Guide v3 geht auf folgende Aspekte beim Penetrationstesten ein [21]: Informationsbeschaffung Testen der Konfiguration Testen der Authentifizierung Testen der Sessionverwaltung Testen der Autorisierung Testen der Business Logik

24 3 Stand der Forschung Testen der Datenvalidierung Denial of Service Anfälligkeit testen Testen der Webservices Testen von AJAX Innerhalb dieser Abschnitte wird zudem sehr detailliert auf Teilaspekte, wie z.b. das Testen nach SQL-Injections bei der Datenvalidierung, eingegangen. Es werden außerdem viele Beispiele und nützliche Applikationen vorgestellt [21] Open Source Security Testing Methodology Manual (OSSTMM) Das Open Source Security Testing Methodology Manual (OSSTMM) wurde von der Non- Profit-Organisation ISECOM entwickelt und veröffentlicht. OSSTMM beschreibt eine Vorgehensweise mit der eine gesamte Organisation auf Sicherheitsaspekte überprüft werden kann. Hierfür werden Metriken zur Einschätzung des Sicherheitslevels sowie drei Sicherheitsklassen 1 vorgestellt. Diese können zudem mit fünf Kanälen 2 untergliedert werden [24]. Zur Durchführung des Penetrationtests werden 17 Module vorgeschlagen, die für jeden Kanal durchlaufen werden sollten. Bei einem vollständigen Test müssen somit 17 5 = 85 Tests durchgeführt werden [24] Information Systems Security Assessment Framework (ISSAF) Ebenso wie OWASP und ISECOM ist auch die Organisation Open Information Systems Security Group (OISSG), die das Information Systems Security Assessment Framework (ISSAF) entwickelt und veröffentlicht hat, unabhängig und nicht profitorientiert [24]. ISSAF definiert eine Methodologie zur Evaluierung der Netzwerk-, System- und Applikationssicherheit. Hierfür werden drei Phasen vorgegeben: Die Planungs- und Vorbereitungsphase, die Bewertungsphase sowie die Bericht-, Aufräum- und Artefakt-Zerstörungsphase [24]. Im Mittelpunkt des Frameworks steht die Bewertungsphase, welche ein Vorgehen zum Penetrationstesten beschreibt. Es wird auf folgende Aspekte eingegangen [24]: Informationsbeschaffung Netzwerkabbildung Schwachstellenidentifikation Penetration Zugriffserlangung und Privilege Escalation Kompromittierung anderer Benutzer/Webseiten 1 physische Sicherheit, Spektrum-Sicherheit und Kommunikationssicherheit 2 physisch, menschlich, drahtlos, Telekommunikation und Datennetzwerk 16

25 3.2 Sicherheit von Datenbanken Aufrechterhalten des Zugriffs Spuren verwischen Anwendbarkeit auf NoSQL-Datenbanken Sowohl der OWASP Testing Guide als auch OSSTMM und ISSAF stellen generische Vorgehensweisen zur Sicherheitsanalyse von Webapplikationen vor. Ziel dieser Arbeit ist allerdings speziell NoSQL-Datenbanken zu untersuchen. Da bei diesen Systemen viele Angriffe, wie zum Beispiel eine SQL-Injection, nicht möglich sind, müssen zur Vereinfachung des Penetrationstests viele nicht zutreffende generische Aspekte ausgeblendet oder angepasst werden. Als Grundlage für eine zugeschnittene Methodik zur Sicherheitsanalyse von NoSQL- Datenbanken bietet sich besonders der OWASP Testing Guide an, da dieser klar strukturiert ist und die wichtigsten Aspekte kompakt zusammenfasst. Vielversprechend ist außerdem die Bewertungsphase von ISSAF, die auf das Penetrationstesten von Webapplikationen eingeht. Auch hier muss überprüft werden, welche Aspekte relevant für NoSQL-Datenbanken sind. OSSTMM bietet sich dagegen nur sehr bedingt für diese Arbeit an, da dieses Handbuch sehr komplex ist und zudem die Sicherheit einer gesamten Organisation abdeckt. 3.2 Sicherheit von Datenbanken Inhalt dieser Arbeit ist es nicht nur aufzuzeigen mit welcher Methodik NoSQL-Datenbanken auf Sicherheitsaspekte untersucht werden können, sondern auch festzustellen, wie fortgeschritten derzeit der Sicherheitsstand von repräsentativen NoSQL-Systemen ist. Deshalb wird in diesem Abschnitt in einem ersten Schritt der Forschungsstand im Bereich der Sicherheit von relationalen Datenbanken aufgezeigt. Anschließend wird in einem zweiten Schritt darauf eingegangen, wie weit der Sicherheitsstand von NoSQL- Datenbanken erforscht wurde Sicherheit von relationalen Datenbanken Im Gegensatz zu NoSQL-Datenbanken, die sich erst seit dem Web 2.0 großer Beliebtheit erfreuen, werden relationale Datenbanken schon seit über zwanzig Jahren 3 eingesetzt. Dementsprechend fortgeschritten ist auch die Forschung im Bereich der Sicherheit dieser Systeme. Im Laufe der Jahre wurden zahlreiche wissenschaftliche Arbeiten veröffentlicht, die Konzepte und Mechanismen zur Steigerung der Sicherheit von relationalen Datenbanken vorschlagen. Erwähnenswert ist hier beispielsweise der Artikel An Authorization Mechanism for a Relational Database System. Griffiths und Wade haben in dieser Arbeit 3 vgl. MySQL, siehe zuletzt abgerufen am

26 3 Stand der Forschung bereits 1976 ein Konzept zur Autorisierung vorgestellt. Heute kann man sagen, dass die populärsten Vertreter der relationalen Datenbanken, wie z.b. MySQL [20], alle relevanten Sicherheitsmechanismen anbieten. Trotz dieser Sicherheitskonzepte ist es in manchen Fällen dennoch möglich, in relationale Datenbanken einzudringen. In dem Artikel Security and Control Issues within Relational Databases beschreibt Ogbolumani unter anderem die wichtigsten Sicherheitsrisiken von relationalen Datenbanken: Missbrauch von Rechten Schwache Authentifizierung Schwache Systemkonfiguration Datenbank- und Betriebssystemschwachstellen Schwachstellen in der Front-End-Applikation Backupschwachstellen Auch das Bundesamt für Sicherheit in der Informationstechnik definiert eine Reihe an Gefährdungen für relationale Datenbanken. Diese lassen sich grob in vier Kategorien einteilen [4]: 1. Organisatorische Mängel 2. Menschliche Fehlhandlungen 3. Technisches Versagen 4. Vorsätzliche Handlungen Zu diesen Kategorien werden zahlreiche, potentiell gefährliche Aspekte aufgezählt und ausführlich beschrieben. Zusätzlich liefert das BSI Maßnahmenempfehlungen, um die aufgezählten Gefährdungen zu relativieren. Diese orientieren sich am Lebenszyklus eines Datenbankssystems und können wie folgt gegliedert werden [4]: 1. Planung und Konzeption 2. Beschaffung 3. Umsetzung 4. Betrieb 5. Notfallvorsorge Zu diesen Punkten bzw. Phasen des Datenbanklebenszyklus zeigt das BSI zahlreiche Maßnahmen zur Prävention bzw. Reaktion auf. 18

27 3.2 Sicherheit von Datenbanken Sicherheit von NoSQL-Datenbanken Wie bereits in Kapitel erwähnt wurde, sind NoSQL-Datenbanken noch ziemlich jung, Neo4j ist beispielsweise erst im Jahr erschienen. Aus diesem Grund haben sehr viele NoSQL-Systeme noch nicht alle relevanten Sicherheitsmechanismen umgesetzt. Dies liegt unter anderem auch daran, dass der Fokus dieser Datenbankkategorie auf den neuartigen Datenmodellen liegt, um sich von relationalen Systemen abzugrenzen. Zu diesem Resultat kommt auch die 2011 veröffentlichte Arbeit Security Issues in NoSQL Databases von Okman u. a.. In diesem Werk werden die NoSQL-Datenbanken MongoDB und Cassandra auf Sicherheitsdefizite überprüft und Empfehlungen zur Steigerung der Sicherheit aufgezeigt. Zusätzlich zu den Gefährdungen relationaler Datenbanken gibt es laut Urbanski bei vielen NoSQL-Datenbanken zusätzlich weitere Angriffsmöglichkeiten, die auf der Konferenz OWASP AppSecUSA 2012 im Rahmen des Vortrags NoSQL, no security? vorgestellt wurden. Zu der Sicherheit von NoSQL-Datenbanken gibt es noch viele weitere Vorträge, wie z.b. NoSQL No Injection von Huang auf der DEF CON 18 sowie Abusing NoSQL-Databases von Chow auf der DEF CON 21, aber auch Blogartikel, wie beispielsweise von Shimel [26] und Penchikala [23]. All diese Veröffentlichungen haben gemeinsam, dass diese zum größten Teil bereits überholt sind. Der Grund hierfür ist, dass NoSQL-Datenbanken noch sehr jung sind und sich deshalb auch sehr schnell weiterentwickeln. Erforschte Sicherheitsdefizite werden somit auch sehr schnell behoben Vergleich der Sicherheit von relationalen- und NoSQL-Datenbanken Aus Kapitel geht bereits hervor, dass die populärsten relationalen Datenbanken mittlerweile alle relevanten Sicherheitskonzepte, wie beispielsweise eine Authentifizierung oder Autorisierung, unterstützen. Allerdings kann trotz dieser Vorkehrungen keine hundertprozentige Sicherheit gewährleistet werden. Neben technischen Defekten können auch organisatorische Mängel, menschliche Fehlbehandlungen sowie vorsätzliche Handlungen dazu führen, dass die Sicherheitsmechanismen der Datenbank umgangen werden können. Diese Sicherheitsrisiken können aber stark minimiert werden, indem beispielsweise die Maßnahmenempfehlungen des BSI bzw. standardisierte Prozesse zur Sicherung der Datenbank angewendet werden. Zusammenfassend kann behauptet werden, dass die Sicherheit von relationalen Datenbanken sehr umfangreich erforscht wurde. Es sind sowohl die möglichen Sicherheitsrisiken als auch die Maßnahmen, um diese einzudämmen, bekannt. Ein Blick auf den Stand der Forschung der Sicherheit von NoSQL-Datenbanken (siehe Kapitel 3.2.2) zeigt dagegen ein komplett anderes Bild: Im Gegensatz zu relationalen Datenbanken sind diese einem sehr starken Wandel unterzogen. Zum einen werden für 4 vgl. zuletzt abgerufen am

28 3 Stand der Forschung die populären NoSQL-Datenbanken immer weitere Funktionen veröffentlicht, wie zum Beispiel Sicherheitsmechanismen oder neue Abfragemöglichkeiten. Zum anderen erscheinen aber auch immer weitere, neuartige NoSQL-Vertreter, die einen anderen Ansatz verfolgen als deren Konkurrenten. Bei den sicherheitsanalysierenden Veröffentlichungen zu NoSQL-Datenbanken zeigt sich allerdings ein komplett anderes Bild: Neben der im Jahre 2011 erschienenen Arbeit Security Issues in NoSQL Databases von Okman u. a., lassen sich nur noch Vorträge oder nicht wissenschaftliche Blogartikel über die Thematik finden, die in den meisten Fällen auch nicht mehr aktuell sind. Zusammenfassend kann gesagt werden, dass bereits sicherheitsanalysierende Veröffentlichungen zu NoSQL-Systemen existieren und zudem viele Aspekte, wie Sicherheitsrisiken und Maßnahmenempfehlungen, von relationalen Datenbanken übertragen werden können. Aufgrund des schnellen Wandels in der NoSQL-Welt ist es sehr wahrscheinlich, dass die veröffentlichten Sicherheitsdefizite von NoSQL-Datenbanken nicht mehr aktuell sind. Deshalb muss überprüft werden, ob diese noch präsent sind und ob bereits neue Gefährdungen existieren (siehe Kapitel 4). Außerdem muss gezeigt werden, wie diese Sicherheitsrisiken anhand einer gegebenen NoSQL-Datenbank überprüft werden können (siehe Kapitel 5). 3.3 Schlussfolgerungen Im Rahmen dieses Kapitels wurde festgestellt, dass existierende Methodologien, wie der OWASP Testing Guide, OSSTMM oder ISSAF, nur sehr bedingt zur Sicherheitsanalyse von NoSQL-Datenbanken eingesetzt werden können. All diese Ansätze haben gemeinsam, dass sie sehr umfangreich sind und ein Großteil der darin enthaltenen Informationen nicht auf NoSQL-Datenbanken angewendet werden kann. Um eine effiziente Sicherheitsanalyse zu ermöglichen, muss deshalb eine speziell auf NoSQL-Datenbanken zugeschnittene Methodik entworfen werden. Als Grundlage hierfür bietet sich der OWASP Testing Guide an. Ein weiteres Ergebnis dieses Kapitels ist, dass relationale Datenbanksysteme bei Einhaltung standardisierter Prozesse zur Sicherstellung der Datenbanksicherheit (z.b. durch die Maßnahmenempfehlungen des BSI) als sicher eingestuft werden können. Dagegen kann bei NoSQL-Datenbanken keine generelle Aussage über deren Sicherheitsstand getroffen werden. Dies liegt zum einen an dem schnellen Wandel in der NoSQL-Welt und zum anderen an dem Mangel an verwertbaren Sicherheitsanalysen. Deshalb ist mit der zu erforschenden Methodik zu überprüfen, wie der derzeitige Sicherheitsstand ausgewählter NoSQL-Vertreter ist. 20

29 4 Sicherheitsrisiken von NoSQL-Datenbanken Ziel dieser Arbeit ist, eine Methodik aufzuzeigen, die es ermöglichen soll, NoSQL- Datenbanken effizient auf Sicherheitsdefizite zu untersuchen. Um dies zu gewährleisten, müssen in einem ersten Schritt die wichtigsten Sicherheitsrisiken von NoSQL-Systemen identifiziert werden. Diese fungieren als Grundlage für die Vorgehensweise zur Sicherheitsanalyse in Kapitel 5 und werden in den folgenden Abschnitten vorgestellt. 4.1 Schwache Konfiguration Ein großes Sicherheitsrisiko von NoSQL-Systemen ist eine schwache Konfiguration. Der Grund hierfür ist simpel: Implementierte Sicherheitsmechanismen einer Datenbank sind nutzlos, wenn sie nicht durch eine Konfiguration aktiviert sind. Die meisten NoSQL-Systeme können nach der Installation direkt gestartet werden. Initial verwenden diese eine sogenannte Standardkonfiguration, die bereits die wichtigsten Einstellungsparameter, wie zum Beispiel den zu verwendenden Port, auf definierte Standardwerte setzt. Viele Funktionen werden von derartigen Konfigurationen allerdings nicht berücksichtigt, wie beispielsweise oft wichtige Sicherheitsmechnismen. Diese können zwar nachträglich aktiviert werden, dies wird aber von sehr vielen Entwicklern vergessen. Wie bereits erwähnt, werden bei dem ersten Start vieler NoSQL-Datenbanken die wichtigsten Parameter auf Standardwerte gesetzt. Ein großes Risikopotential bergen häufig auch Parameter, die auf den ersten Blick nicht sicherheitsrelevant zu sein scheinen: Das Paradebeispiel hierfür ist der Standardport, der de facto von jeder NoSQL-Datenbank initial gesetzt wird. Diese Information hilft einem Angreifer ein vorhandenes NoSQL- System zu identifizieren und auf Sicherheitsdefizite zu überprüfen. Auf eine schwach konfigurierte NoSQL-Datenbank ist folgendes Angriffsszenario denkbar: 1. Ein Angreifer findet auf dem zu testenden Server einen offenen Port und erfährt durch eine schnelle Internetsuche, dass dies der Standardport einer NoSQL- Datenbank ist. 2. In der Bedienungsanleitung des NoSQL-Systems sind Standard-Authentifizierungsdaten notiert, die dem Angreifer Zugriff auf das System geben.

30 4 Sicherheitsrisiken von NoSQL-Datenbanken 3. Nutzungsbeschränkungen wurden nicht konfiguriert Der Angreifer hat vollen Schreib-/Lesezugriff auf die Datenbank. 4.2 Unzureichende Datenvalidierung Wie bereits in Kapitel festgestellt wurde, bieten relationale Datenbanken mittlerweile ausreichend viele Sicherheitsmechanismen an, um die enthaltenen Daten vor Angreifern zu schützen. In den Medien tauchen trotzdem häufig Meldungen über gigantische Datendiebstähle von relationalen Datenbanken auf. Hierfür werden von den Angreifern meist sogenannte SQL-Injections verwendet. Dieser Angriff zielt darauf ab, dass Benutzereingaben von der verwendeten (Web-)Applikation nicht ausreichend überprüft werden und somit SQL-Fragmente in die Abfragen eingeschleust werden können. Dies ermöglicht je nach Schwere der Schwachstelle Daten unberechtigt zu lesen oder sogar zu verändern. Zum Schutz bieten fast alle relationalen Datenbanken Prepared Statements an, die es ermöglichen, eine SQL-Injection zu verhindern. Aus Unwissenheit oder Bequemlichkeit wird dieses Konzept von Entwicklern aber häufig nicht verwendet, was zu besagten Datendiebstählen führen kann. Nach diesem Exkurs stellt sich nun die Frage, ob auch NoSQL-Datenbanken anfällig für Angriffe sind, die auf eine unzureichende Datenvalidierung abzielen. Die Frage lässt sich klar bejahen: Die meisten NoSQL-Systeme verwenden zwar kein SQL, bieten stattdessen aber andere Abfragesprachen oder -möglichkeiten, wie z.b. Cypher bei Neo4j oder das Map/Reduce-Konzept bei CouchDB an. Oft sind diese noch nicht ganz ausgereift, was dazu führt, dass diese noch Schwachstellen enthalten, die bei SQL bereits vor Jahren korrigiert wurden (siehe in Kapitel 6.2.2). Bei einigen NoSQL- Datenbanken eröffnen sich aber auch viele ganz neue Angriffsmöglichkeiten, die auf eine unzureichende Validierung der Eingabedaten abzielen. Allgemein kann hier zwischen drei Varianten unterschieden werden [29]: Query-Injections entsprechen den SQL-Injections bei NoSQL-Datenbanken. Es können hiermit je nach Abfragesprache und Schwere der Sicherheitslücke Daten gelesen und geschrieben werden [29]. Schema-Injections nutzen aus, dass viele NoSQL-Vertreter schemafrei sind oder nur schwache Schemarestriktionen besitzen. Mithilfe dieses Angriffs können beispielsweise neue Attribute in der Datenbank hinzugefügt oder bereits existierende, wie z.b. ein Passwort-Feld, überschrieben werden [29]. Sehr gefährlich sind JavaScript-Injections. JavaScript wird von einigen NoSQL-Datenbanken angewendet, um Map/Reduce-Abfragen zu beschreiben und das Fehlen von SQL-Funktionen zu kompensieren. Gelingt es einem Angreifer JavaScript einzuschleusen, so kann potentiell eine Vielzahl von Angriffen ausgeführt werden. Laut Sullivan sind folgende Anwendungsszenarien denkbar: Denial of Service (DOS) 22

31 4.3 Fehlende oder schwache Kryptographie Dateisystem-Zugriff Aufbau eines Webservers (z.b. mittels Node.js) Ausführen von Binärdateien Es ist also möglich, dass der Datenbankserver sowohl lahmgelegt (DOS-Attacke) als auch komplett übernommen werden kann (Kombination von Node.js-Server, Dateisystem- Zugriff und evtl. Ausführen von Binärdateien). Wie diese Angriffe durchgeführt werden können, wird in der Methodik in Kapitel näher beschrieben [27]. 4.3 Fehlende oder schwache Kryptographie Ein häufig als gering eingeschätztes Sicherheitsrisiko ist eine schwache oder fehlende Kryptographie der Daten bzw. der Datenströme: Bei einem relationalen System sollten beispielsweise die Verbindungen zum Server (z.b. mit SSL) sowie die Datenbankinhalte auf der Festplatte (z.b. mit AES) mit kryptographischen Verfahren geschützt werden. Da bei NoSQL-Systemen oft mehrere Server zur besseren Skalierung eingesetzt werden, müssen hier zusätzlich die Verbindungen zwischen den Instanzen abgesichert werden. Nicht zu vergessen ist außerdem eine adäquate Verschlüsselung der Datenbank-Backups, die von vielen NoSQL-Systemen automatisch angelegt werden und die Absicherung der Benutzerpasswörter von den Anwendern der Datenbank. Dass eine Verschlüsselung sehr wichtig ist, zeigen folgende Beispiele: Werden die Daten zum oder zwischen den Servern in Klartext übertragen, so kann ein Angreifer, der Zugriff auf die Kommunikation hat, ohne Probleme die ausgetauschten Informationen mitlesen. Es reicht hierfür oft schon, wenn sich der Angreifer im gleichen Netzwerk wie ein Klient befindet, der auf die Datenbank zugreift. Diese Angriffsmethode wird auch als Man-in-the-Middle-Angriff bezeichnet. Sind die Daten bzw. die Backups einer NoSQL-Datenbank nicht ausreichend verschlüsselt, so kann ein Angreifer durch das Aufsetzen einer neuen NoSQL-Datenbankinstanz mit z.b. einem Backup auf alle Inhalte des ursprünglichen Systems zugreifen. Liegen einem Angreifer außerdem die gespeicherten Zugangsdaten, wie z.b. Benutzerpasswörter, vor, so kann sich dieser bei dem System authentifizieren und unbefugt auf Daten zugreifen, sofern die Zugangsdaten nicht abgesichert sind. 4.4 Zusammenfassung Das größte Sicherheitsrisiko von NoSQL-Datenbanken ist eine schwache Konfiguration. Hier sind folgende Aspekte besonders gefährlich: 1. In der Konfiguration sind wichtige Sicherheitsmechanismen nicht aktiviert. 2. Die Standardkonfiguration enthält keine bzw. nicht alle Sicherheitseinstellungen. 23

32 4 Sicherheitsrisiken von NoSQL-Datenbanken 3. Es werden Standardwerte verwendet, die es einem Angreifer leicht machen, das System zu identifizieren oder sogar zu infiltrieren. Ein weiteres Sicherheitsrisiko, welches bei relationalen bzw. generell Datenbanken zu gigantischen Datendiebstählen geführt hat, ist eine unzureichende Datenvalidierung. Allgemein kann hier bei NoSQL-Datenbanken zwischen drei Angriffsvarianten unterschieden werden: 1. Query-Injection 2. Schema-Injection 3. JavaScript-Injection Eine schwache oder gar fehlende Kryptographie stellt ebenso ein Sicherheitsrisiko dar. Folgende Daten bzw. Datenströme sollten mittels kryptographischer Verfahren abgesichert werden: 1. Verbindungen zwischen den Klienten und der Datenbank 2. Verbindungen zwischen den Datenbankinstanzen 3. Datenbank-Inhalte auf den Festplatten 4. Datenbank-Backups 5. Benutzerpasswörter 24

33 5 Methodik zur Sicherheitsanalyse von NoSQL-Datenbanken Testphase Informationsbeschaffung Risikobewertung Abbildung 5.1: Methodik zur Sicherheitsanalyse von NoSQL-Datenbanken In diesem Kapitel wird eine Methodik vorgestellt, die es ermöglicht, NoSQL-Datenbanken effizient auf Sicherheitsdefizite zu untersuchen. Grundlage dieser Vorgehensweise sind die in Kapitel 4 aufgezeigten Sicherheitsrisiken. Diese werden nun wieder aufgegriffen und es wird gezeigt, wie eine NoSQL-Datenbank auf diese Schwachstellen überprüft werden kann. Wie in Abbildung 5.1 zu sehen ist, kann die Methodik in drei aufeinander aufbauende Schritte unterteilt werden: Informationsbeschaffung, Testphase und Risikobewertung. Im Abschnitt Informationsbeschaffung wird gezeigt, wie beim Identifizieren potentieller Sicherheitsdefizite einer NoSQL-Datenbank vorgegangen werden kann und welche Aspekte hierbei besonders wichtig sind. Aufbauend auf den Erkenntnissen der Informationsphase wird im Abschnitt Testphase gezeigt, wie eine NoSQL-Datenbank auf die gefundenen Sicherheitsdefizite getestet werden kann. In dem Abschnitt Risikobewertung wird anschließend erläutert, wie die identifizierten Schwachstellen entsprechend des Risikos bewertet werden können.

34 5 Methodik zur Sicherheitsanalyse von NoSQL-Datenbanken 5.1 Informationsbeschaffung Bei jedem Penetrationtest bzw. jeder Sicherheitsanalyse ist der erste Schritt die Informationsbeschaffung. Allgemein wird hier versucht, so viele Informationen wie möglich über das zu testende System zu ermitteln. Das Spektrum der gesuchten Daten reicht von Webservereigenschaften, über verwendete Webframeworks, bis hin zu spezifischeren Informationen, wie z.b. der Applikationsarchitektur (siehe [21]). Da im Rahmen dieser Arbeit NoSQL-Datenbanken und nicht komplette Server auf Sicherheitsaspekte analysiert werden sollen, genügt es die zu ermittelnden Daten auf NoSQL-Systeme zu beschränken. Eine der Kerneigenschaften von NoSQL-Datenbanken ist, dass diese meist Open Source sind. Dies vereinfacht den Prozess der Informationbeschaffung immens, da aufgrund der Quelloffenheit der zu untersuchenden Datenbanken meist sehr ausführliche und tiefgehende Dokumentationen existieren. Diese enthalten sehr viele interessante Informationen für die Sicherheitsanalyse. Eine gute Quelle der Informationsbeschaffung stellt also die Dokumentation dar. Diese sollte gezielt durchgearbeitet werden. Des Weiteren sollte überprüft werden, ob nicht bereits Sicherheitsdefizite über die zu untersuchende NoSQL-Datenbank veröffentlicht wurden. Hierfür reicht meist schon eine einfache Internetsuche. In den folgenden Abschnitten wird aufgezeigt, welche Aspekte bei der Informationsbeschaffung besonders wichtig sind und wie mögliche Sicherheitsdefizite aufgedeckt werden können. Hierbei werden die Sicherheitsrisiken von Kapitel 4 wieder aufgegriffen Konfiguration Wie bereits in Kapitel 4.1 erwähnt wurde, stellt eine schwache Konfiguration das größte Sicherheitsrisiko von NoSQL-Datenbanken dar. Deshalb ist es sehr wichtig, die folgenden Informationen über die Konfiguration des zu prüfenden NoSQL-Systems einzuholen. Konfigurierbare Sicherheitsmechanismen und Abdeckung der Standardkonfiguration prüfen In den meisten Dokumentationen befindet sich ein Kapitel zur Sicherheit. Dieses erleichtert die Zusammenstellung von allen konfigurierbaren Sicherheitsmechanismen sehr stark. Trotzdem muss in vielen Fällen länger gesucht bzw. eine Beispieldatenbank aufgesetzt werden, um vorhandene Sicherheitsmechanismen zu identifizieren. Das Ergebnis dieses Abschnitts sollte eine tabellarische Aufzählung aller vorhandener Sicherheitsmechanismen sein. Zusätzlich soll (falls vorhanden) eine Beschreibung zur Aktivierung und ein Standardwert vermerkt werden. Auch fehlende essentielle Schutzfunktionen sollten erwähnt werden. 26

35 5.1 Informationsbeschaffung Als Vorlage kann die folgende Tabelle verwendet werden, welche beliebig erweitert werden kann: Sicherheitsmechanismus Aktivierung Standardwert Authentifizierung Nicht vorhanden Nicht vorhanden Autorisierung Parameter in Konfigurationsdatei Deaktiviert Logging Parameter in Konfigurationsdatei Deaktiviert Kryptographie Clientverbindung Parameter in Konfigurationsdatei Deaktiviert Serversynchronisation Nicht vorhanden Nicht vorhanden Backups Nicht vorhanden Nicht vorhanden Daten Nicht vorhanden Nicht vorhanden Benutzerpasswörter Immer aktiviert MD5-Hashing Tabelle 5.1: Sicherheitsmechanismen der zu testenden NoSQL-Datenbank Nützliche Standardwerte/Informationen identifizieren Nicht zu vergessen sind außerdem Standardwerte, die auf den ersten Blick nicht gefährlich sind, aber sich trotzdem als nützlich erweisen könnten. Hierfür sollte falls vorhanden sowohl das Kapitel Konfiguration in der Dokumentation als auch die Konfigurationsdateien beleuchtet werden. Die Ergebnisse sollen anschließend ebenso tabellarisch mit Bezeichnung und Standardwert festgehalten werden. Als Vorlage hierfür kann die folgende Tabelle verwendet werden, welche beliebig erweitert werden kann: Bezeichnung (Standard-)Wert Port (HTTP) 1234 Port (HTTPS) 4321 Standard-Logindaten User = Admin, Password = Admin Admin-Webinterface Pfad: Tabelle 5.2: Nützliche Standardwerte/Informationen der zu testenden NoSQL-Datenbank Datenvalidierung Bezüglich der Datenvalidierung gibt es bei NoSQL-Datenbanken drei verschiedene Angriffsmöglichkeiten: Query-Injections, Schema-Injections und JavaScript-Injections 27

36 5 Methodik zur Sicherheitsanalyse von NoSQL-Datenbanken (siehe Kapitel 4.2). Hierbei ist zu beachten, dass nicht bei jedem NoSQL-System jeder Angriff auf die Datenvalidierung möglich ist und oft Schutzmechanismen existieren. In den folgenden Abschnitten wird in einem ersten Schritt aufgezeigt, welche Voraussetzungen die Angriffe auf die Datenvalidierung haben und auf welche Aspekte besonders Acht gegeben werden sollte. Anschließend wird darauf eingegangen, welche allgemeinen Schutzmechanismen existieren könnten und welche Informationen diesbezüglich eingeholt werden sollten. Query-Injection Query-Injections entsprechen den SQL-Injections aus der relationalen Datenbankenwelt. Die Voraussetzung für diese Art von Angriff ist, dass die zu untersuchende NoSQL- Datenbank eine Abfragesprache anbietet, die ähnlich oder äquivalent zu SQL ist. Falls JavaScript eingesetzt wird, sollte ein Blick auf den Abschnitt zu JavaScript-Injections geworfen werden. Sehr positiv für Penetrationtester ist hier, dass SQL-Injections im Bereich der relationalen Datenbanken bereits sehr gut erforscht sind. Aufgrund der starken Ähnlichkeit von Query-Injections kann sich ein Angreifer an der Trickkiste von SQL-Injections bedienen und prüfen, ob diese bei der zu untersuchenden NoSQL-Datenbank eingesetzt werden können. Bei der gegebenen NoSQL-Abfragesprache sind mithilfe der Dokumentation folgende Konzepte von SQL-Injections auf Anwendbarkeit zu überprüfen: 1. Verwenden von Anführungszeichen ( oder ), um die Abfrage zu verändern. Beispiel aus SQL: SELECT user, password FROM USERS WHERE user = "[Wert]" Wird hier für [Wert] z.b. x OR 1 = 1 eingetragen, so werden alle existierenden Benutzer ausgegeben. 2. Verwenden eines Kommentars (z.b. mit // oder ), um die Abfrage zu verändern. Beispiel aus SQL: SELECT password FROM USERS WHERE user = "[Wert]" AND userrole = " constructor" Wird hier für [Wert] z.b. x OR 1 = 1 eingetragen, so werden in diesem Fall alle Passwörter ausgegeben. 3. Einschleusen einer zweiten Abfrage/Aktualisierung (z.b. mit einem Semikolon). Beispiel aus SQL: SELECT user, password FROM USERS WHERE user = "[Wert]" 28

37 5.1 Informationsbeschaffung Wird hier für [Wert] z.b. x" OR "1" = "1"; INSERT INTO USERS(user, password, userrole) VALUES("christoph", "password", "admin"); eingetragen, so werden in diesem Fall sowohl alle Benutzer ausgegeben als auch ein neuer Administrator mit dem Namen christoph erstellt. Schema-Injection Schema-Injections zielen darauf ab, dass viele NoSQL-Vertreter schemafrei sind oder nur schwache Schemarestriktionen besitzen. Eine zwingende Voraussetzung von Schema- Injections stellt also die Schemafreiheit der zu untersuchenden NoSQL-Datenbank dar. Ist diese Voraussetzung erfüllt, so muss anhand der Dokumentation überprüft werden, wie das Verhalten der Datenbank bei folgenden Anwendungsfällen ist: 1. Können ohne Einschränkungen neue Attribute/Werte hinzugefügt werden? Wenn nein, welche Einschränkungen gibt es? 2. Wie reagiert das System auf nicht eindeutige NoSQL-Abfragen? (Z.B. zwei Schreibanweisungen für ein Feld) JavaScript-Injection JavaScript wird von einigen NoSQL-Datenbanken angewendet, um Map/Reduce-Abfragen zu realisieren und das Fehlen von SQL-Funktionen zu kompensieren. Bietet die zu untersuchende Datenbank kein JavaScript oder ähnliche Programmiersprachen in Abfragen an, so kann keine JavaScript-Injection durchgeführt werden. Es ist also zu überprüfen, ob das NoSQL-System JavaScript in deren Abfragen zulässt. Ist dies der Fall, müssen folgende Fragen geklärt werden: 1. Bei welchen Konstrukten kann JavaScript eingesetzt werden? 2. Welche JavaScript-Operationen sind zulässig? 3. Welche Schutzmaßnahmen gegen JavaScript-Injections existieren? Schutzmechanismen Alle der gezeigten Angriffe auf die Datenvalidierung können mittels einer Sicherheitsüberprüfung der Eingabedaten abgewehrt werden. Relationale Datenbanken wehren SQL-Injections mittels sogenannter Prepared Statements ab. Diese prüfen die Daten, welche in eine Abfrage eingetragen werden, auf deren Gültigkeit. Erst nach dieser Überprüfung wird das SQL-Statement ausgeführt. 29

38 5 Methodik zur Sicherheitsanalyse von NoSQL-Datenbanken Derartige Konzepte gibt es auch in der NoSQL-Welt, deshalb ist allgemein zu prüfen, ob die zu untersuchende NoSQL-Datenbank derartige Schutzmechanismen anbietet und, ob diese verbindlich sind. Bei vielen NoSQL-Vertretern werden die Client-Bibliotheken zur Abfrage von Daten nicht vom Anbieter selbst, sondern von der Community veröffentlicht. Deshalb ist es durchaus möglich, dass z.b. eine Java-API clientseitige Schutzmechanismen wie Prepared Statements anbietet, eine PHP-API allerdings nicht. Da NoSQL-Datenbanken noch nicht in der Breite eingesetzt werden, macht es zudem Sinn, einen Blick auf die meist öffentlichen Implementierungen der Schutzmechanismen zu werfen Kryptographie Im Rahmen der Informationsbeschaffung müssen folgende Daten bezüglich der Kryptographie in Erfahrung gebracht werden: Können die folgenden Daten bzw. Datenverbindungen mittels kryptographischer Verfahren abgesichert werden? Wenn ja, welche Verschlüsselung bzw. welcher Hashingalgorithmus wird verwendet? 1. Verbindungen zwischen den Klienten und der Datenbank 2. Verbindungen zwischen den Datenbankinstanzen 3. Datenbank-Inhalte auf den Festplatten 4. Datenbank-Backups 5. Benutzerpasswörter Des Weiteren ist zu überprüfen, welche Zertifikate eingesetzt werden und wo diese gespeichert werden. 5.2 Testphase Der nächste Schritt der Methodik stellt die Testphase dar. Das Ziel der Testphase ist die zu überprüfende NoSQL-Datenbank auf die in der Informationsbeschaffung ermittelten Sicherheitsdefizite zu überprüfen. Für diese Phase ist es notwendig eine Testinstanz der NoSQL-Datenbank anzulegen bzw. ein vorhandenes NoSQL-System zu verwenden. Eine gute Anleitung zum Aufsetzen einer neuen Datenbankinstanz befindet sich meist in der Dokumentation, diese kann ohne Weiteres verwendet werden. Falls bereits eine zu testende NoSQL-Datenbank existiert, ist sicherzustellen, dass das zu System seitens des Datenbankbetreibers auf die im Folgenden beschriebenen Verfahren getestet werden darf. Hierfür muss eine Erlaubnis von dem Betreiber der NoSQL-Datenbank eingeholt werden. 30

39 5.2 Testphase In den folgenden Abschnitten wird demonstriert, wie bei dem Testen der Konfiguration, Datenvalidierung und der Kryptographie vorzugehen ist und welche Besonderheiten hierbei zu beachten sind Testen der Konfiguration Im Rahmen der Informationsbeschaffung wurden zwei Tabellen erstellt, die sowohl alle konfigurierbaren Sicherheitsmechanismen und deren Abdeckung durch die Standardkonfiguration aufzeigen als auch nützliche Informationen/Standardwerte liefern (siehe Kapitel 5.1.1). Diese Informationen sollen nun wieder aufgegriffen und auf die zu testende Datenbank angewendet werden. Standardwerte auf Anwendbarkeit prüfen In einem ersten Schritt muss überprüft werden, ob die ermittelten Standardwerte/Informationen angewendet werden können. Bei den Beispielinhalten von Tabelle 5.2 kann dies wie folgt erledigt werden: Ports Zum Herausfinden, ob die gegebenen Ports geöffnet sind, kann das Programm nmap 1 oder eine vergleichbare Applikation verwendet werden. Standard-Logindaten Zum Überprüfen der Anwendbarkeit der Standard-Logindaten muss eine Datenbankabfrage mit den gegebenen Benutzerdaten formuliert werden. Falls die Logindaten falsch waren, wird von der NoSQL-Datenbank ein Fehler zurückgegeben. Admin-Webinterface Die Zugänglichkeit des Admin-Webinterfaces kann überprüft werden, indem die in der Dokumentation enthaltene URL ausprobiert wird. NoSQL-Datenbank auf aktivierte Sicherheitsmechanismen überprüfen In einem zweiten Schritt muss überprüft werden, ob die in Tabelle 5.1 enthaltenen Sicherheitsmechanismen überhaupt aktiviert sind. Da die von der Standardkonfiguration nicht abgedeckten Schutzmaßnahmen am erfolgversprechendsten sind, sollte bei diesen mit der Überprüfung begonnen werden. Als Hilfestellung für diesen Schritt soll nun beispielhaft gezeigt werden, wie überprüft werden kann, ob die vorhandenen Sicherheitsmechanismen aktiviert sind. Falls im Vergleich zu Tabelle 5.1 zusätzliche Schutzmaßnahmen gefunden wurden, muss für 1 siehe zuletzt abgerufen am

40 5 Methodik zur Sicherheitsanalyse von NoSQL-Datenbanken diese individuell ein Weg zur Überprüfung der Aktivität gefunden werden. In der Regel unterscheidet sich hier das Vorgehen allerdings nur sehr gering. Authentifizierung Das Vorhandensein einer Authentifizierung kann sehr einfach überprüft werden: Hierfür muss lediglich eine Datenbankabfrage formuliert werden, die trotz Unwissenheit des Datenschemas ausgeführt werden kann und eine Authentifizierung verlangt. Autorisierung Die Voraussetzung zum Überprüfen einer aktivierten Autorisierung ist, dass der Tester bereits Zugang zur Datenbank (z.b. mit Benutzerdaten) hat. Ist dies der Fall, so kann durch Beispielabfragen ermittelt werden, ob bzw. welche Operationen durch eine Autorisierung (nicht) möglich sind. Empfehlenswert ist in einem ersten Schritt zu testen, ob globale Lese-, Schreibrechte gestattet sind. In einem zweiten Schritt sollten einzelne Tabellen (bzw. deren NoSQL-Äquivalent) auf Lese-, Schreibrechte untersucht werden. Logging Ohne einen Einblick in die Konfigurationsdateien der Datenbank ist es meist sehr schwer zu überprüfen, ob die zu testende Datenbank Benutzeraktionen protokolliert. Dennoch ist dies in Ausnahmefällen möglich: Einige NoSQL-Vertreter, wie Neo4j und CouchDB, zeigen alle Konfigurationsparameter im Administrations- Webinterface an. Fehlt eine Authentifizierung und eine ausreichende Autorisierung, so kann ein Angreifer die Logging-Konfiguration einsehen und diese gegebenenfalls modifizieren. Kryptographie Zu überprüfen, ob bei einer Datenbank kryptographische Verfahren eingesetzt werden, ist ein schwierigeres Unterfangen, deshalb wird dies gesondert beschrieben (siehe Kapitel 5.2.3) Testen der Datenvalidierung In der Regel bietet jede NoSQL-Datenbank eine Schnittstelle an, über die Anfragen direkt an das NoSQL-System gestellt werden können. Im Hinblick auf die Datenvalidierung ist diese Abfragevariante allerdings die am wenigsten geschützte. Der Grund hierfür ist, dass die Datenvalidierung meist auf die Client-Bibliotheken der Datenbank ausgelagert werden. Um zu überprüfen, ob die zu testende Datenbank für die im Rahmen der Informationsbeschaffung gefundenen Defizite in der Datenvalidierung (siehe Kapitel 5.1.2) anfällig ist, sollte in einem ersten Schritt überprüft werden, ob die direkte Datenbankschnitt- 32

41 5.2 Testphase stelle mit den ermittelten Sicherheitslücken angreifbar ist. Anschließend sollten die Client-Bibliotheken unter die Lupe genommen werden. In den folgenden Abschnitten wird gezeigt, wie sowohl die direkte Datenbankschnittstelle als auch die Client-Bibliotheken auf Anwendbarkeit der Angriffe auf die Datenvalidierung getestet werden können. Datenbankschnittstelle auf Anwendbarkeit der Angriffe auf die Datenvalidierung überprüfen Zum Testen der Datenbankschnittstelle sollten zu allen möglichen Injection-Varianten Beispielabfragen formuliert werden, welche die in der Informationsbeschaffung ermittelten Angriffe auf die Datenvalidierung ausprobieren. Konkret heißt dies, dass zum Testen von Query-Injections Beispielabfragen formuliert werden müssen, die die ermittelten Modifikationen einer Abfrage (z.b. mit einem Kommentar oder Anführungszeichen) testen. Zum Testen von Schema-Injections müssen Abfragen formuliert werden, die je nach den Ergebnissen der Informationsbeschaffung neue Attribute hinzufügen oder alte Attributwerte überschreiben. JavaScript-Injections können getestet werden, indem Beispielabfragen mit JavaScript- Codefragmenten formuliert werden, die ausgehend von den Ergebnissen der Informationsphase prüfen, ob und welche Injektionen möglich sind. Konkret heißt dies für die in Kapitel 4.2 aufgezählten Anwendungsszenarien folgendes: Denial of Service (DOS) Ein DOS-Angriff kann mit einer einfachen while(1)-schleife realisiert werden. Alternativ kann der Datenbankprozess mittels process.exit() oder process.kill (process.pid) beendet werden [27]. Dateisystem-Zugriff Auf das Dateisystem kann mit Hilfe des fs-moduls zugegriffen werden [27]: 1 var fs = require( fs ) ; 2 // Lesen 3 var dircontent = fs.readdirsync(. ). tostring () ; 4 // Schreiben 5 var curfile = process.argv[1]; 6 fs. writefilesync(curfile, inject + fs. readfilesync(currentfile)) ; Aufbau eines Webservers Ein Node.js-Server kann mit folgendem JavaScript-Programmcode erstellt werden [27]: 1 var http = require( http ) ; 33

42 5 Methodik zur Sicherheitsanalyse von NoSQL-Datenbanken 2 3 http.createserver(function (request, response) { 4 if (request.method === POST ) { 5 request.addlistener( data, function(chunk) { 6 // Programmcode 7 }) ; 8 request.addlistener( end, function() { 9 // Programmcode 10 }) ; 11 } 12 } Ausführen von Binärdateien Durch den Zugriff auf das Dateisystem können auch Binärdateien geschrieben werden. Diese können mit dem folgenden Kommando ausgeführt werden [27]: 1 require( child_process ). spawn(filename); Das Ergebnis dieser Tests sollte eine Liste aller anwendbarer Angriffe auf die Datenvalidierung sein. Client-Bibliotheken auf Anwendbarkeit der Angriffe auf die Datenvalidierung überprüfen Die Voraussetzung für den Test der Client-Bibliotheken ist, dass diese überhaupt für die zu testende Datenbank existieren. Besonders junge NoSQL-Vertreter besitzen oft noch keine derartigen Bibliotheken. Da einige NoSQL-Datenbanken sehr viele Client- Bibliotheken anbieten, macht es zudem Sinn, sich bei diesem Test auf die Gebräuchlichsten zu beschränken. Es ist aber durchaus nicht falsch, auch einen Blick auf die restlichen Bibliotheken zu werfen. Die Grundlage für diesen Abschnitt stellen alle anwendbaren Angriffe auf die Datenvalidierung dar, welche anhand der Datenbankschnittstelle verifiziert wurden (siehe vorheriger Abschnitt). In der Regel bieten die Client-Bibliotheken sowohl die Möglichkeit an, Daten mittels Prepared Statements als auch mit normalen Statements abzufragen. Beide Varianten sollten auf die Anfälligkeit gegenüber den verifizierten Angriffen auf die Datenvalidierung überprüft werden. Dies kann dadurch realisiert werden, indem eine (Test-)Applikation programmiert wird, die sowohl Daten mittels einem Prepared Statements als auch mit Hilfe eines normalen Statements abfragt. Analog zu dem vorherigen Abschnitt muss nun nur noch mittels Beispielabfragen getestet werden, ob die Statementvarianten ebenso anfällig für die gefundenen Sicherheitsdefizite sind. 34

43 5.2 Testphase Testen der Kryptographie Da beim Testen der Kryptographie der Datenverbindungen, der Daten/Backups/Benutzerpasswörter ein komplett verschiedenes Vorgehen benötigt wird, werden beide Vorgehensweisen separat in den folgenden Abschnitten erläutert. Testen der Kryptographie der Datenverbindungen Zur Überprüfung der Verschlüsselung der Datenverbindungen muss folgende Voraussetzung gegeben sein: Der Tester muss entweder Zugriff auf den Datenverkehr zwischen der Datenbank und den Endknoten/anderen Datenbankinstanzen oder zumindest einen Auszug davon (z.b. in Form eines TCP-Dumps) haben. Ist diese Voraussetzung gegeben, so kann mittels eines sogenannten Sniffers (Programm zur Analyse von Netzwerk-Kommunikationsverbindungen) der Datenverkehr aufgezeichnet und analysiert werden. Empfehlenswert ist hierfür das Programm Wireshark 2, welches alle notwendigen Werkzeuge zur Ermittlung der Verschlüsselung mitbringt. Mit Wireshark kann ein aufgezeichneter Datenverkehr wie folgt auf die Verschlüsselung analysiert werden: Wird bei den gegebenen Paketen HTTP als verwendetes Protokoll angezeigt, so ist die Datenverbindung sehr wahrscheinlich unverschlüsselt und kann mitgelesen werden. Dies kann verifiziert werden, indem ein Blick auf die versendeten Daten geworfen wird. Werden andererseits TLSv1.X sowie TCP als Protokoll angezeigt, so liegt auf der Hand, dass als Verschlüsselung SSL eingesetzt wird. Ein Blick auf den Abschnitt Secure Socket Layer in den Paketdetails verrät sogar, welche Verschlüsselung genau verwendet wird (siehe Cipher Spec). Es macht durchaus Sinn die verwendete Verschlüsselung mittels einer Internetsuche zu überprüfen und Schwachstellen auszuschließen. Für den Fall, dass nur TCP Pakete angezeigt werden, muss individuell überprüft werden, ob die Daten verschlüsselt oder in Klartext übertragen werden. Hierfür sollte ein Blick auf die Rohdaten der TCP-Pakete geworfen werden. Testen der Kryptographie der Daten/Backups und Benutzerpasswörter Zum Überprüfen der Verschlüsselung der Daten/Backups müssen die zu testenden Daten/Backups der NoSQL-Datenbank vorliegen. Für den Fall, dass der Tester Zugriff auf diese Daten hat, kann sehr einfach festgestellt werden, ob diese ausreichend gesichert sind: Es muss eine neue NoSQL-Datenbankinstanz aufgesetzt werden, die die Rohdaten der zu testenden Datenbank bzw. ein Backup als Basis verwendet. Startet dieses Testsystem ohne Fehlermeldungen bzw. einer Passwortanfrage und zeigt alle enthaltenen Daten an, so ist entweder keine Verschlüsselung vorhanden oder diese wurde von der NoSQL-Datenbank selbst ausgehebelt. 2 siehe zuletzt abgerufen am

44 5 Methodik zur Sicherheitsanalyse von NoSQL-Datenbanken Zum Überprüfen der Verschlüsselung bzw. des Hashalgorithmus der Benutzerpasswörter müssen diese ebenso vorliegen. Anhand der Länge der vorliegenden Passwörter kann leicht festgestellt werden, ob diese gehasht wurden oder nicht: Sind die vorliegenden Passwörter meist kürzer als 10 Zeichen, so kann davon ausgegangen werden, dass diese unverschlüsselt/ungehasht vorliegen. Dies kann durch eine Beispielabfrage einfach verifiziert werden. Ansonsten wurden die Passwörter sehr wahrscheinlich mittels eines Hashalgorithmus gehasht. Für diesen Fall existieren viele Programme (wie z.b. John the Ripper 3 ), die sowohl den verwendeten Hashalgorithmus als auch die eigentlichen Passwörter oder Kollisionen hiervon ermitteln können. 5.3 Risikobewertung Die ermittelten Schwachstellen der zu testenden NoSQL-Datenbanken können mithilfe der OWASP Risk Rating Methodology des OWASP Testing Guides (siehe [22]) entsprechend des Risikos bewertet werden. Die Risikobewertung von OWASP wurde speziell für die Applikationssicherheit optimiert und eignet sich deshalb optimal für NoSQL- Datenbanken. Allgemein kann das Risiko mittels folgender Formel bestimmt werden [22]: Risiko = Eintrittswahrscheinlichkeit Auswirkung OWASP definiert zur Bestimmung dieses Risikofaktors folgende sechs Schritte [22]: 1. Risikoidentifizierung 2. Faktoren zur Bestimmung der Eintrittswahrscheinlichkeit 3. Faktoren zur Bestimmung der Auswirkung 4. Ermitteln des Ausmaßes des Risikos 5. Entscheiden, was behoben werden soll 6. Anpassen des Risikobewertungsmodells Bei dieser Vorgehensweise ist zu beachten, dass die Schritte 1 bis 4 sich auf ein einzelnes Risiko und dessen Bewertung beziehen. Für den 5. Teil müssen bereits alle Risiken bewertet worden sein. Dieser beschreibt, in welcher Reihenfolge die Risiken bearbeitet werden sollten. In Schritt 6 wird erklärt, wie das Risikobewertungsmodell angepasst werden kann [22]. In den folgenden Abschnitten wird erläutert, wie die bisher ermittelten Schwachstellen der zu testenden NoSQL-Datenbank entsprechend des Risikos bewertet werden können. 3 siehe zuletzt abgerufen am

45 5.3 Risikobewertung Risikoidentifizierung Im Rahmen der Risikoidentifizierung müssen folgende Informationen erfasst werden [22]: 1. Die gefundene Schwachstelle 2. Der Angriff zum Ausnutzen der Schwachstelle 3. Möglicher worst-case Thread Agent 4. Auswirkungen eines erfolgreichen Angriffs auf das Unternehmen Die Schwachstellen stellen die Ergebnisse der Informationsbeschaffung (nicht verifiziert) bzw. der Testphase (verifiziert) dar und können einfach übernommen werden. Die Angriffe zum Ausnutzen der gefundenen Schwachstellen wurden ebenfalls in der Testphase vorgestellt und können auch übernommen werden [22]. Als nächstes muss ein Threat Agent bestimmt werden. Mit diesem Begriff wird ein Individuum bzw. eine Gruppe bezeichnet, die eine Gefahr darstellen könnte. Thread Agents können wie folgt klassifiziert werden [22]: Nicht-Ziel spezifisch (z.b. Computerviren) Beschäftigte Organisierte Verbrecher (z.b. Kriminelle, die Bankdaten ergattern möchten) Andere Körperschaften (z.b. andere Unternehmen) Menschen, unbeabsichtigt (z.b. eine nicht gewollte Handlung) Menschen, beabsichtigt (z.b. Insider) Naturbedingte Ursachen (z.b. Feuer) Als Thread Agent sollte immer das Individuum bzw. die Gruppe gewählt werden, die im schlimmsten Fall eine Gefahr darstellen könnte [22]. Die Auswirkungen eines erfolgreichen Angriffs auf das Unternehmen müssen individuell entschieden werden [22] Faktoren zur Bestimmung der Eintrittswahrscheinlichkeit OWASP unterscheidet bezüglich der Eintrittswahrscheinlichkeit zwei Arten von Faktoren: Threat Agent-Faktoren sowie Schwachstellen-Faktoren. Diese werden wiederum in zu bewertende Unterfaktoren aufgeteilt. Es können jeweils Bewertungen von 0 bis 9 vergeben werden, die in einem späteren Schritt zu der Eintrittswahrscheinlichkeit zusammengefasst werden (siehe Kapitel 5.3.4) [22]. Folgende Faktoren müssen bewertet werden, um die Eintrittswahrscheinlichkeit bestimmen zu können [22]: Threat Agent-Faktoren 37

46 5 Methodik zur Sicherheitsanalyse von NoSQL-Datenbanken 1. Kompetenzlevel Wie kompetent ist die Gruppe der Threat Agents? (9) Penetrationtest-Fähigkeiten, (6) Netzwerk- und Programmierfähigkeiten, (4) Mittlere technische Fähigkeiten, (1) Keine technische Fähigkeiten 2. Motiv Wie motiviert ist die Gruppe der Threat Agents, um die Schwachstelle zu finden und auszunutzen? (9) Hohe Belohnung, (4) Mögliche Belohnung, (1) Keine oder eine kleine Belohnung 3. Möglichkeit Welche Ressourcen und Möglichkeiten sind für die Threat Agents erforderlich, um die Schwachstelle zu finden und auszunutzen? (9) Kein Zugriff oder Ressourcen erforderlich, (7) Wenig Zugriff oder Ressourcen, (4) Spezieller Zugriff oder Ressourcen, (0) Vollzugriff oder teure Ressourcen 4. Größe Wie groß ist die Gruppe an Threat Agents? (9) Anonyme Internet-Benutzer, (6) Authentifizierte Benutzer, (5) Beschäftigte, (4) Intranet-Benutzer, (2) System-Administratoren, (2) Entwickler Schwachstellen-Faktoren 1. Schwierigkeitsgrad der Entdeckung Wie einfach ist es für die Threat Agents, die Schwachstelle zu entdecken? (9) Automatisierte Anwendungen erhältlich, (7) Einfach, (3) Schwer, (1) Praktisch unmöglich 2. Schwierigkeitsgrad des Ausnutzens Wie einfach ist es für die Threat Agents, die Schwachstelle auszunutzen? (9) Automatisierte Anwendungen erhältlich, (5) Einfach, (3) Schwer, (1) Theoretisch 3. Bekanntheit Wie weit bekannt ist die Schwachstelle der Gruppe an Threat Agents? (9) Öffentlich bekannt, (6) Unübersehbar, (4) Versteckt, (1) Nicht bekannt 4. Angriffsentdeckung Wie wahrscheinlich ist die Entdeckung des Angriffs? (9) Nicht protokolliert, (8) Protokolliert ohne Begutachtung, (3) Protokolliert und begutachtet, (1) Aktive Entdeckung in der Applikation 38

47 5.3 Risikobewertung Faktoren zur Bestimmung der Auswirkung Auch bei der Auswirkungsbestimmung unterscheidet OWASP zwei Arten von Faktoren: Faktoren mit technischen Auswirkungen sowie Faktoren mit Auswirkungen auf das Unternehmen. Auch hier müssen wieder Bewertungen von 0 bis 9 vergeben werden, die in einem späteren Schritt zu der resultierenden Auswirkung zusammengefasst werden (siehe Kapitel 5.3.4) [22]. Folgende Faktoren müssen bewertet werden, um die Auswirkung bestimmen zu können [22]: Faktoren mit technischen Auswirkungen 1. Vertraulichkeitsverlust Wie viele Daten könnten offengelegt worden sein und wie vertraulich könnten diese gewesen sein? (9) Alle Daten, (7) Sehr viele kritische Daten, (6) Sehr viele unkritische Daten, (6) Wenige kritische Daten, (2) Wenige unkritische Daten 2. Integritätsverlust Wie viele Daten könnten beschädigt worden sein? (9) Alle Daten total beschädigt, (7) Sehr viele Daten ernsthaft beschädigt, (5) Sehr viele Daten leicht beschädigt, (3) Wenige Daten ernsthaft beschädigt, (1) Wenige Daten leicht beschädigt 3. Verfügbarkeitsverlust Sind (wichtige) Dienste nicht mehr verfügbar? (9) Alle Dienste sind komplett nicht verfügbar, (7) Sehr viele Primärdienste sind unterbrochen, (5) Sehr viele Sekundärdienste sind unterbrochen, (5) Wenige Primärdienste sind unterbrochen, (1) Wenige Sekundärdienste sind unterbrochen 4. Verlust der Rechenschaft Können Aktionen der Threat Agents Personen zugeordnet werden? (9) Komplett anonym, (7) Zuordnung möglich, (1) Zuordnung komplett möglich Faktoren mit Auswirkungen auf das Unternehmen 1. Finanzieller Schaden Welcher finanzielle Schaden kann durch die Schwachstelle entstehen? (9) Insolvenz, (7) Erheblicher Einfluss auf jährlichen Profit, (3) Wenig Einfluss auf jährlichen Profit, (1) Weniger als die Kosten, um die Schwachstelle zu beseitigen 2. Rufschädigung 39

48 5 Methodik zur Sicherheitsanalyse von NoSQL-Datenbanken Kann die Schwachstelle zu einer Rufschädigung führen, die dem Unternehmen schaden könnte? (9) Markenschädigung, (5) Verlieren von Vertrauen, (4) Verlieren von wichtigen Kunden, (1) Minimaler Schaden 3. Non-Compliance Wie viel Belastung bewirkt Non-Compliance? (7) Große Verletzung des Profils, (5) Klare Verletzung, (2) Geringe Verletzung 4. Datenschutzverletzung Wie viele personenbezogene Daten konnten entwendet werden? (9) Millionen an Personen, (7) Tausende an Personen, (5) Hunderte an Personen, (3) Eine indiduelle Person Ermitteln des Ausmaßes des Risikos In diesem Schritt werden die Bewertungen von den vorherigen zwei Abschnitten wieder aufgegriffen und zu einer finalen Eintrittswahrscheinlichkeit sowie einem finalen Auswirkungswert verrechnet. Die resultierenden Werte werden anschließend verwendet, um eine Aussage über das Ausmaß des Risikos zu geben. Zur Bestimmung der finalen Werte muss der Durchschnitt aus den Bewertungen der Faktoren der vorherigen Abschnitte gebildet werden. Hierzu müssen diese addiert und durch die Anzahl der Bewertungen geteilt werden. Zu beachten ist allerdings, dass bei der Eintrittswahrscheinlichkeit der Durchschnitt aus den Bewertungen beider Faktoren gebildet wird. Bei der Auswirkungsbestimmung muss allerdings für die technischen Auswirkungen sowie Auswirkungen auf das Unternehmen ein jeweils gesonderter Durchschnitt berechnet werden. Die resultierenden Werte müssen anschließend den Klassen GERING (0 bis <3), MITTEL (3 bis <6) und HOCH (6 bis 9) zugeordnet werden [22]. Ist dies erledigt, muss das Ausmaß des Risikos der gefundenen Schwachstelle ermittelt werden. Sofern gute Informationen bezüglich der Auswirkungen auf das Unternehmen vorliegen, sollte der hierauf bezogene Durchschnittswert verwendet werden. Falls es allerdings nur wenige Informationen diesbezüglich gibt, sollte der Wert der technischen Auswirkungen herangezogen werden. Anhand der folgenden Tabelle 5.3 kann anschließend das resultierende Ausmaß des Risikos abgelesen werden [22] Welche Schwachstelle soll behoben werden? Nachdem alle Schwachstellen entsprechend des Risikos bewertet wurden, stellt sich die Frage, in welcher Reihenfolge diese behoben werden sollten. An erster Stelle sollten immer die Schwachstellen eliminiert werden, die das größte Sicherheitsrisiko darstellen. Weniger ernste Defizite sollten, auch wenn sie günstig zu 40

49 5.4 Zusammenfassung Auswirkung HOCH Mittel Hoch Kritisch MITTEL Gering Mittel Hoch GERING Gering Gering Mittel GERING MITTEL HOCH Eintrittswahrscheinlichkeit Tabelle 5.3: Risikoausmaßbestimmung (nach [22]) beheben sind, hinten angestellt werden. Außerdem ist es erwähnenswert, dass nicht alle Schwachstellen eliminiert werden müssen. Wenn das Risiko in keiner Relation zu den Behebungskosten steht, können diese auch vernachlässigt werden [22]. 5.4 Zusammenfassung Die Methodik zur Sicherheitsanalyse von NoSQL-Datenbanken lässt sich in drei aufeinander aufbauende Phasen gliedern: Informationsbeschaffung, Testphase und Risikobewertung. In der Informationsbeschaffung sollen alle für die Testphase benötigten Informationen ermittelt werden. Um diesen Vorgang zu erleichtern, wurde für jedes Sicherheitsrisko aus Kapitel 4 aufgezeigt, welche spezifischen Informationen hierfür eingeholt werden müssen. Außerdem wurde beschrieben, wie die ermittelten Resultate dargestellt werden können. Die Testphase hat zwei primäre Ziele: Zum einen sollen die Ergebnisse der Informationsbeschaffung validiert werden, zum anderen ist zu ermitteln, ob ein gegebenes Testsystem anfällig für die ermittelten Sicherheitsdefizite ist. Ähnlich wie bei der Informationsbeschaffung, werden auch hier für jedes Sicherheitsrisiko Empfehlungen zur Vorgehensweise gegeben. Die dritte und letzte Phase der Methodik ist die Risikobewertung. Analog zum OWASP Testing Guide wird hier gezeigt, wie die ermittelten Sicherheitsdefizite entsprechend des Risikos bewertet werden können. Außerdem wird beschrieben, wie die als erstes zu behebende Schwachstelle ausgewählt werden kann. 41

50

51 6 Validierung am Beispiel der NoSQL-Datenbank Neo4j Abbildung 6.1: Logo der NoSQL-Datenbank Neo4j 1 Das Ziel dieses Kapitels ist zu zeigen, wie die Methodik zur Sicherheitsanalyse (siehe Kapitel 5) auf die NoSQL-Graphdatenbank Neo4j angewendet werden kann, um potentielle Sicherheitsdefizite aufzudecken und zu bewerten. Hierfür wird in einem ersten Schritt eine kurze Einführung in Neo4j gegeben, um diese Datenbank von anderen NoSQL-Systemen abzugrenzen und deren Funktionsweise vorzustellen. Hier wird außerdem aufgezeigt, wie die für die Sicherheitanalyse relevante Testinstanz von Neo4j aufgebaut ist und wie diese konfiguriert wurde. In einem zweiten Schritt wird die Sicherheitsanalyse von Neo4j unter Verwendung der Methodik aus Kapitel 5 durchgeführt und vorgestellt. Abschließend werden die Ergebnisse der Sicherheitsanalyse von Neo4j wieder aufgegriffen und analysiert. 6.1 Einführung in Neo4j Vor der eigentlichen Sicherheitsanalyse einer NoSQL-Datenbank macht es Sinn, sich mit der Funktionsweise und den Eigenschaften des NoSQL-Systems vertraut zu machen. Des Weiteren muss ein Testsystem aufgesetzt werden, welches in der späteren Sicherheitsanalyse wieder aufgegriffen wird. Anschließend werden Beispielabfragen aufgeführt, um eine kurze Einführung in die Abfragesprache von Neo4j zu geben und der Testdatenbank Daten hinzuzufügen. 1 Quelle: zuletzt abgerufen am

52 6 Validierung am Beispiel der NoSQL-Datenbank Neo4j Einordnung und Charakterisierung Die NoSQL-Datenbank Neo4j ist eine der populärsten Vertreter der Kategorie der Graphdatenbanken. Wie bereits in Kapitel erwähnt wurde, enthalten diese Systeme Knoten (Entitäten), welche mit Kanten (Relationen) assoziiert werden können. Beide Datentypen können bei Neo4j mit beliebig vielen Attributen versehen werden, außerdem kann den Kanten eine Richtung zugewiesen werden. Das resultierende Konstrukt aus Knoten und Kanten wird als Graph bezeichnet. Neo4j ermöglicht das Ausführen von optimierten Abfragen auf einem derartigen Graphen [10]. Da in der NoSQL-Welt viele weitere Graphdatenbanken existieren, soll nun Neo4j von den anderen Vertretern dieser Kategorie abgegrenzt werden. Hierfür werden die charakteristischen Eigenschaften von Kapitel wieder herangezogen. Konsistenz 1. Welches Konsistenzmodell (z.b. ACID oder BASE) wird verwendet? Neo4j ist eines der wenigen NoSQL-Systeme, welches komplett ACID-konform ist. Der Grund hierfür ist, dass die Datenbank auf einer stark verbundenen Datenstruktur operiert, was ein hohes Maß an Konsistenz erfordert [10]. 2. Wie werden die Daten konsistent gehalten, wenn nur ein Server verwendet wird? Die Daten auf einem einzelnen Server sind immer konsistent. Transaktionen stellen sicher, dass keine toten Kanten generiert werden [10]. 3. Wie werden die Daten konsistent gehalten, wenn diese auf viele Server verteilt sind? Es wird eine Master-Slave-Replikation angeboten, die wie folgt funktioniert: Ein Schreibvorgang auf die Master-Instanz wird eventuell (entweder sofort oder zeitversetzt) mit den Slave-Instanzen synchronisiert. Slave-Instanzen sind immer für Lesevorgänge verfügbar. Schreibvorgänge auf Slaves sind ebenfalls erlaubt und werden sofort mit der Master-Instanz synchronisiert, allerdings nicht mit den anderen Slave- Instanzen. Diese werden durch den Master auf den aktuellsten Stand gebracht [10]. Transaktionen 1. Werden Transaktionen bzw. transaktionsähnliche Mechanismen angeboten? Neo4j ist ACID-konform, deshalb werden auch Transaktionen angeboten. Bei einem Schreibvorgang muss eine Transaktion verwendet werden, bei einem Lesevorgang kann eine Transaktion verwendet werden [10]. 44

53 6.1 Einführung in Neo4j Verfügbarkeit 1. Bietet die Datenbank Replikation an? Es wird eine Master-Slave-Replikation angeboten (siehe Konsistenz) [10]. 2. Wird Sharding unterstützt? Sharding wird derzeit nicht unterstützt [10]. Abfragemöglichkeiten 1. Werden von der Datenbank Abfragesprachen angeboten? Wenn ja, wie mächtig sind diese? Offiziell wird von Neo4j Cypher als Abfragesprache angeboten. Alternativ kann auch Gremlin eingesetzt werden, allerdings wird diese Abfragesprache nicht mehr offiziell unterstützt [10]. 2. Wie können Indizes erstellt werden? Mittels Cypher und der Anweisung CREATE INDEX können Knotenattribute indiziert werden Wie können Abfragen ausgeführt werden und welche Konzepte werden hierfür verwendet? Neo4j bietet eine REST-API an, über die alle Datenbankoperationen durchgeführt werden können [10]. Es werden 31 Client-Bibliotheken für unterschiedliche Programmiersprachen und Frameworks angeboten 3. All diese Implementierungen greifen über die REST-API-Schnittstelle auf die Datenbank zu. Skalierung 1. Welche Möglichkeiten zur Skalierung werden angeboten? Es gibt drei Möglichkeiten, um Neo4j zu skalieren: a) Falls genügend Arbeitsspeicher (RAM) vorhanden ist, können alle Daten von Neo4j im RAM gehalten werden. Dies führt zu einem starken Performancegewinn. b) Des Weiteren können weitere Slave-Instanzen hinzugefügt werden, was zumindest die Lesegeschwindigkeit deutlich erhöht. c) Außerdem können die Daten seitens der Applikation auf viele Server verteilt werden (Sharding), wobei hier sichergestellt werden muss, dass zusammengehörige Informationen auf denselben Servern abgelegt sein sollten [10]. 2 siehe zuletzt abgerufen am siehe zuletzt abgerufen am

54 6 Validierung am Beispiel der NoSQL-Datenbank Neo4j Testaufbau Penetrationtester Personensuche 1 2 Traversierung 3 PHP-Applikationen Neo4j Cluster Abbildung 6.2: Testaufbau Neo4j Wie in Abbildung 6.2 zu sehen ist, besteht das Testsystem aus einem Cluster mit drei Neo4j-Instanzen sowie zweier PHP-Applikationen. Bei der Erstellung des Neo4j-Clusters wurde die von Neo4j veröffentlichte Anleitung High Availability setup tutorial 4 verwendet, welche genau beschreibt, wie bei der Erstellung eines derartigen Clusters vorzugehen ist. Die Neo4j-Instanzen haben folgende Ports: Die Ports 5001 (Instanz 1), 5002 (Instanz 2) und 5003 (Instanz 3) werden verwendet, um Cluster-Informationen auszutauschen. Die Ports 6363 (Instanz 1), 6364 (Instanz 2) und 6365 (Instanz 3) dienen dem Datenaustausch zwischen den Cluster-Instanzen. Jede Instanz besitzt außerdem einen Backup-Server mit den folgenden Ports: 6366 (Instanz 1), 6367 (Instanz 2) und 6368 (Instanz 3). Die Ports 7474 (Instanz 1), 7475 (Instanz 2) und 7476 (Instanz 3) werden für den HTTP-Zugriff und die Ports Ports 7484 (Instanz 1), 7485 (Instanz 2) und 7486 (Instanz 3) für den HTTPS Zugriff verwendet. Für die Neo4j-Instanzen wird die Neo4j Enterprise Edition eingesetzt. 4 siehe zuletzt abgerufen am

55 6.1 Einführung in Neo4j Des Weiteren beinhaltet das Testsystem zwei PHP-Applikationen, welche auf die Neo4j- Datenbank zugreifen. Die Anwendung Personensuche generiert eine Suchmaske und zeigt die Ergebnisse der Suche in Form einer Tabelle an. Die Anwendung Traversierung generiert ebenfalls eine Suchmaske, die eine Traversierung durchführt. Die Ergebnisse der Traversierung werden tabellarisch dargestellt. Zum Zugriff auf Neo4j wird die Client- Bibliothek Neo4jPHP verwendet. Ausschnitte der Quelltexte der Applikationen können in Kapitel A.1 eingesehen werden. Damit bei der Sicherheitsanalyse von Neo4j sämtliche Aspekte überprüft werden können, hat der Penetrationstester sowohl Zugriff auf die PHP-Applikationen als auch auf die Neo4j-Instanzen Beispielabfragen In diesem Abschnitt soll anhand von Beispielabfragen erläutert werden, wie bei Neo4j sowohl Knoten als auch Kanten generiert und abgefragt werden können. Die angegebenen Abfragen werden auf der Neo4j-Testdatenbank ausgeführt, die zu Beginn weder Knoten noch Kanten beinhaltet. Angenommen es soll ein Knoten erstellt werden, welcher eine Person mit einem Namen, einem Geschlecht sowie einem Geheimnis widerspiegelt. Dies kann mit folgender Abfrage realisiert werden: CREATE (n:person { name : Franz, geschlecht : maennlich, geheimnis : mag seinen Beruf nicht }) Das n in dieser Abfrage kann als Variable interpretiert werden. Person bzw. der Ausdruck hinter einem Doppelpunkt wird als Label bezeichnet. In den geschweiften Klammern befinden sich die Attribute zusammen mit den Attributwerten des zu erzeugenden Knotens. Es sollen nun die Personen Sissi, Romeo, Julia und Peter hinzugefügt werden: CREATE (n:person { name : Sissi, geschlecht : weiblich, geheimnis : liebt heimlich Romeo }); CREATE (n:person { name : Romeo, geschlecht : maennlich, geheimnis : liebt heimlich Franz }) ; CREATE (n:person { name : Julia, geschlecht : weiblich, geheimnis : ist nicht gluecklich }) ; CREATE (n:person { name : Peter, geschlecht : maennlich, geheimnis : ist ueberarbeitet }) ; Es soll nun eine Abfrage erstellt werden, welche die Attributwerte der Person mit dem Namen Sissi zurückliefert: MATCH (x:person) WHERE x.name = Sissi RETURN x 47

56 6 Validierung am Beispiel der NoSQL-Datenbank Neo4j MATCH entspricht in etwa dem SELECT von SQL. Es wird nach Knoten x mit dem Label Person gesucht, die den Namen Sissi haben. Diese Einschränkung der Ergebnismenge wird durch den Operator WHERE realisiert. Als letztes wird x, also in diesem Fall Sissi, zurückgegeben. Es können allerdings auch mehrere Knoten zurückgegeben werden. Nun soll eine Kante erstellt werden, die signalisiert, dass Sissi mit Franz verheiratet ist: MATCH (a:person),(b:person) WHERE a.name = Sissi AND b.name = Franz CREATE (a) [r:verheiratet] >(b) RETURN r In einem ersten Schritt werden hier die Knoten von Sissi (= a) und Franz (= b) ermittelt. Anschließend wird eine gerichtete Kante r von a nach b mit dem Label Verheiratet erstellt. Die Relation r wird anschließend zurückgegeben. Es soll nun abschließend eine Abfrage erstellt werden, die den Ehepartner von Sissi zurückliefert: MATCH (x:person { name : Sissi }) (y:person) RETURN y Diese Abfrage sucht nach allen Relationen die zwischen einer Person x mit dem Namen Sissi und einer anderen Person existieren. Da nur die Verheiratet-Relation erstellt wurde, wird nur für diese y, also Franz, zurückgeliefert. 6.2 Sicherheitsanalyse von Neo4j Nun soll die Methodik zur Sicherheitsanalyse von NoSQL-Datenbanken aus Kapitel 5 auf Neo4j angewendet werden. Es soll jede Phase dieser Vorgehensweise durchlaufen werden Informationsbeschaffung Die Grundlage für die Informationsbeschaffung der Sicherheitsanalyse von Neo4j stellt die offizielle Neo4j-Dokumentation [16] dar. Konfiguration Zur Informationsbeschaffung der Konfiguration sind zum einen die konfigurierbaren Sicherheitsmechanismen als auch deren Abdeckung durch die Standardkonfiguration zu ermitteln. Des Weiteren sollen für die Testphase nützliche Standardwerte/Informationen ermittelt werden. 48

57 6.2 Sicherheitsanalyse von Neo4j Konfigurierbare Sicherheitsmechanismen und Abdeckung der Standardkonfiguration Folgende Sicherheitsmechanismen bietet Neo4j an: Sicherheitsmechanismus Aktivierung Standardwert Authentifizierung Nicht vorhanden 5 Deaktiviert 5 Autorisierung Optional mit Security Rule 5 Deaktiviert 5 Server-Logging 6 : INFO: siehe data/log, HTTP-Logging 6 : Deaktiviert Logging Server-Logging 6 : conf/logging.properties, HTTP-Logging 6 : conf/neo4j-server.properties Kryptographie Clientverbindung Parameter in neo4j-server.properties für HTTPS 5 Standard Aktiviert, HTTP ist Serversynchronisation Keine Information Keine Information Backups Nicht vorhanden 7 Nicht vorhanden 7 Daten Nicht vorhanden 7 Nicht vorhanden 7 Benutzerpasswörter Nicht vorhanden 5 Nicht vorhanden 5 Tabelle 6.1: Sicherheitsmechanismen der NoSQL-Datenbank Neo4j Nützliche Standardwerte/Informationen Folgende Informationen können sich in der Testphase als nützlich erweisen: Bezeichnung (Standard-)Wert Port (HTTP) Port (HTTPS) Standard-Logindaten Es gibt keine Authentifizierung 5 Admin-Webinterface Pfad: 8 Öffentliche Erreichbarkeit Einzelner Server: Nicht öffentlich erreichbar 5, HA-Cluster: Öffentlich erreichbar 8 Tabelle 6.2: Nützliche Standardwerte/Informationen der NoSQL-Datenbank Neo4j 5 siehe zuletzt abgerufen am siehe zuletzt abgerufen am siehe zuletzt abgerufen am siehe zuletzt abgerufen am

58 6 Validierung am Beispiel der NoSQL-Datenbank Neo4j Datenvalidierung Bezüglich der Datenvalidierung sind die Angriffe Query-Injection, Schema-Injection sowie JavaScript-Injection zu prüfen. Anschließend wird ein Blick auf die Schutzmechanismen der Datenvalidierung geworfen. Query-Injection Die Voraussetzung von Query-Injections ist, dass die zu untersuchende Datenbank eine Abfragesprache anbietet, die ähnlich oder äquivalent zu SQL ist. Dies trifft bei Neo4j vollends zu, da dessen Abfragesprache Cypher starke Ähnlichkeit zu SQL hat (siehe auch 6.1.3). Laut der Neo4j-Dokumentation sind folgende Query-Injection-Konzepte syntaktisch erlaubt: 1. Verwenden von Anführungszeichen ( oder ), um die Abfrage zu verändern. Cypher lässt sowohl als auch als Anführungszeichen zu. Beispiel: MATCH (x:person) WHERE x.name = "[Wert]" RETURN x Wird hier für [Wert] z.b. x OR 1 = 1 eingetragen, so werden alle existierenden Personen ausgegeben. 2. Verwenden eines Kommentars (z.b. mit // oder ), um die Abfrage zu verändern. Bei Cypher kann mittels // ein Kommentar eingeleitet werden. Beispiel: MATCH (x:person) WHERE x.name = "[Wert]" RETURN x.geschlecht Wird hier für [Wert] z.b. x OR 1 = 1 RETURN x // eingetragen, so werden in diesem Fall statt nur dem Geschlecht alle Daten von allen Personen ausgegeben. 3. Einschleusen einer zweiten Abfrage/Aktualisierung (z.b. mit einem Semikolon). Offiziell bietet Cypher nicht die Möglichkeit an, zwei Abfragen auf einmal auszuführen. Eine weitere Abfrage nach einem Semikolon führt zu einem Fehler. Mittels UNION können allerdings zwei Abfragen fusioniert werden. Ob hiermit auch neue Daten hinzugefügt werden können bzw. die zweite Abfrage Einschränkungen hat, muss in der Testphase überprüft werden. Beispiel: MATCH (x:person) 50

59 6.2 Sicherheitsanalyse von Neo4j WHERE x.name = "[Wert]" RETURN x.geschlecht Wird hier für [Wert] z.b. x" OR "1" = "1" RETURN x UNION ALL CREATE (x:person {name : "Master"}) RETURN x // eingetragen, so sollten in diesem Fall sowohl alle vorhandenen Personen als auch eine neue Person mit dem Namen Master ausgegeben werden. Diese Aufzählung zeigt bereits, dass Neo4j syntaktisch sehr viele Ansatzpunkte für Query-Injections bietet. Seitens der Anwendungen, die auf Neo4j zugreifen, muss deshalb sichergestellt werden, dass derartige Angriffe abgefangen werden. Schema-Injection Die Voraussetzung von Schema-Injections ist die Schemafreiheit der zu testenden NoSQL-Datenbank. Diese ist bei Neo4j erfüllt: Knoten und Kanten können mittels der Operation SET neue Attribute hinzugefügt werden. Laut der Methodik müssen nun folgende Fragen beantwortet werden: 1. Können ohne Einschränkungen neue Attribute/Werte hinzugefügt werden? Wenn nein, welche Einschränkungen gibt es? Mittels Cypher können ohne Einschränkungen neue Attribute hinzugefügt werden. Soll der Person Sissi (Knoten) aus dem Testsystem beispielsweise das Attribut Alter hinzugefügt werden, so kann dies mittels folgender Abfrage realisiert werden: MATCH (n:person { name: Sissi }) SET n.alter = 18 RETURN n 2. Wie reagiert das System auf nicht eindeutige NoSQL-Queries? (Z.B. zwei Schreibanweisungen für ein Feld) Die Syntax von Cypher lässt theoretisch nicht eindeutige Abfragen zu. Beispielsweise könnte ein Feld doppelt beschrieben werden: MATCH (n:person { name: Sissi }) SET n.alter = 18 SET n.alter = 36 RETURN n Ob eine derartige Abfrage akzeptiert wird, ist in der Testphase zu überprüfen. JavaScript-Injection Bei Neo4j ist außerdem die Voraussetzung für JavaScript-Injections gegeben: Eine Suche in der Neo4j-Dokumentation ergibt, dass bei Graph-Traversierungsanfragen JavaScript eingesetzt wird. 51

60 6 Validierung am Beispiel der NoSQL-Datenbank Neo4j Laut der Methodik müssen nun folgende Fragen beantwortet werden: 1. Bei welchen Konstrukten kann JavaScript eingesetzt werden? Laut Dokumentation kann nur bei Traversierungsanfragen über die REST-API von Neo4j JavaScript eingesetzt werden. Diese Programmiersprache wird hier eingesetzt, um die Traversierung einzuschränken (filter) und zu evaluieren (evaluators) 9. Ein Beispiel hierfür befindet sich in Kapitel A Welche JavaScript-Operationen sind zulässig? Laut Dokumentation kann auf die gesamte Neo4j-Java-API zugegriffen werden. Es wird allerdings nicht ausgeschlossen, dass nicht noch andere Anwendungen möglich sind 9. Dies ist in der Testphase zu überprüfen. 3. Welche Schutzmaßnahmen gegen JavaScript-Injections existieren? Die Dokumentation warnt davor, dass JavaScript-Programmcode in Traversierungsanfragen ein Sicherheitsrisiko darstellen könnte 9. Es ist in der Testphase zu überprüfen, ob und welche Angriffe durchgeführt werden können. Schutzmechanismen Die REST-API bietet eine Art Prepared Statement für Cypher-Abfragen an. Ähnlich wie bei SQL werden hier die Stellen, an denen die Parameter eingefügt werden sollen, markiert. Diesen Markierungen können anschließend Werte zugewiesen werden 10. Ein Blick auf die Neo4j-PHP verrät zudem, dass diese Bibliothek, welche den Zugriff auf die Neo4j-Datenbank erleichtern soll, auch dieses Konzept unterstützt. Wie bei SQL ist auch bei Cypher davon auszugehen, dass viele Anwender Parameterwerte direkt in die Abfrage einfügen, was die gezeigten Angriffe ermöglicht. Kryptographie In Tabelle 6.1 können bereits die Ergebnisse der Informationsbeschaffung zur Kryptographie eingesehen werden. Nun soll noch einmal jedes potentiell verwendete kryptographische Verfahren genau unter die Lupe genommen werden. Laut der Dokumentation können die Verbindungen zwischen den Klienten und der Datenbank mittels SSL verschlüsselt werden. Hierfür wird beim ersten Start ein Zertifikat generiert, welches allerdings auch ersetzt werden kann. Obwohl prinzipiell alle Verbindungen zum Server verschlüsselt werden könnten, wird standardmäßig noch die unverschlüsselte HTTP-Verbindung verwendet. Diese Einstellung kann nicht verändert werden. Ob die Verbindungen zwischen den Datenbankinstanzen verschlüsselt sind, geht aus der Dokumentation nicht hervor. Dies muss im Rahmen der Testphase ermittelt werden. 9 siehe zuletzt abgerufen am siehe zuletzt abgerufen am

61 6.2 Sicherheitsanalyse von Neo4j Wie auch in Tabelle 6.1 erwähnt wurde, sind die Datenbank-Inhalte sowie Backups nicht verschlüsselt. Gelangen diese in die falschen Hände, so müsste ein Neuaufsetzen einer neuen Neo4j-Instanz mit diesen Daten möglich sein. Aufgrund der Tatsache, dass die zu untersuchende NoSQL-Datenbank keine Authentifizierung anbietet, gibt es auch keine Absicherung der Benutzerdaten Testphase Die Grundlage für die Testphase ist das in Kapitel beschriebene Testsystem mit den Daten aus Kapitel Testen der Konfiguration In den folgenden zwei Abschnitten werden sowohl die Standardwerte aus Tabelle 6.2 auf Anwendbarkeit als auch die ermittelten Sicherheitsmechanismen aus Tabelle 6.1 auf Aktiviertheit überprüft. Standardwerte auf Anwendbarkeit prüfen Ports Der HTTP- bzw. HTTPS-Port kann sehr einfach überprüft werden, indem in einem Internetbrowser die Ports mitsamt IP-Adresse aufgerufen werden. Bei dem Testsystem z.b. mit :7474 für den HTTP-Port. Sowohl beim HTTP- als auch HTTPS-Port erscheint die Neo4j-Weboberfläche. Die Ports sind also korrekt. Ein nmap-scan des Hosts zeigt, dass alle Ports des HA-Clusters aus dem High Availability setup tutorial 11 auftauchen. Es kann also davon ausgegangen werden, dass nach dieser Anleitung vorgegangen wurde. Admin-Webinterface Das Admin-Interface erscheint unter der URL Aktivierte Sicherheitsmechanismen überprüfen Authentifizierung Es wird auf der Konsole des Admin-Webinterfaces folgende Abfrage ausgeführt: MATCH (n) RETURN n Ohne Authentifizierung werden nun alle Daten ausgegeben. Das Testsystem hat deshalb offensichtlich keine Authentifizierung konfiguriert. Autorisierung Globale Leserechte 11 siehe zuletzt abgerufen am

62 6 Validierung am Beispiel der NoSQL-Datenbank Neo4j Beim Ausführen der folgenden Abfrage werden alle Daten angezeigt: MATCH (n) RETURN n Es bestehen also globale Leserechte. Globale Schreibrechte Beim Ausführen der folgenden Abfragen wird kein Fehler ausgegeben: CREATE (n:test { testfield1 : Testfeld }) ; MATCH (n:test { testfield1 : Testfeld }) SET n.testfield2 = Testfeld2 RETURN n; Es können also sowohl neue Knoten erstellt als auch verändert werden. Offensichtlich bestehen also globale Schreibrechte. Spezielle Leserechte Da globale Leserechte bestehen existieren auch spezielle Leserechte. Spezielle Schreibrechte Beim Ausführen der folgenden Abfrage wird kein Fehler ausgegeben: MATCH (n:person { name : Sissi }) SET n.alter = 36 RETURN n; Es können somit vorhandene Knoten verändert werden. Offensichtlich bestehen also spezielle Schreibrechte. Obwohl nicht alle möglichen Lese- bzw. Schreibabfragen ausprobiert wurden, kann davon ausgegangen, dass keine Autorisierung konfiguriert wurde, da alle Abfragen ohne Komplikationen ausgeführt werden konnten. Logging Das Admin-Webinterface listet unter dem Reiter Server info alle Einstellungen auf. Daraus ist ersichtlich, dass die Standardloggingeinstellungen (siehe Tabelle 6.1) verwendet werden. Die Logs können nicht über das Webinterface gelöscht werden. Kryptographie Eine Datenbank auf kryptographische Verfahren zu testen ist ein schwierigeres Unterfangen. Deshalb wird dies gesondert beschrieben (siehe Testen der Kryptographie). Testen der Datenvalidierung Das Testen der Datenvalidierung lässt sich in zwei Schritte gliedern: In einem ersten Schritt muss überprüft werden, ob die in der Informationsbeschaffung gezeigten Angriffe auf die direkte Datenbankschnittstelle angewendet werden können. 54

63 6.2 Sicherheitsanalyse von Neo4j In einem zweiten Schritt muss überprüft werden, ob die Client-Bibliotheken die verbleibenden möglichen Angriffe filtert oder diese zulässt. Dies wird in den folgenden zwei Abschnitten analysiert. Datenbankschnittstelle auf Anwendbarkeit der Angriffe überprüfen In diesem Abschnitt soll gezeigt werden, wie die in der Informationsbeschaffung gezeigten Angriffe auf die Datenvalidierung direkt an der Datenbankschnittstelle von Neo4j ausprobiert werden können. Query-Injection Zum Testen der Query-Injection-Konzepte aus der Informationsbeschaffung müssen die gezeigten Beispielabfragen lediglich auf der Konsole des Admin-Webinterfaces ausprobiert und auf Fehler überprüft werden. 1. Verwenden von Anführungszeichen ( oder ), um die Abfrage zu verändern. Test folgender Abfrage in der Konsole: MATCH (x:person) WHERE x.name = "x" OR "1" = "1" RETURN x.geheimnis Ergebnis: Alle Geheimnisse werden ausgegeben. Es fehlen allerdings die restlichen Felder. Angriff durchführbar 2. Verwenden eines Kommentars (z.b. mit // oder ), um die Abfrage zu verändern. Test folgender Abfrage in der Konsole: MATCH (x:person) WHERE x.name = "x" OR "1" = "1" RETURN x // " RETURN x.geheimnis Ergebnis: Alle Knoten werden mit allen Attributen ausgegeben. Angriff durchführbar 3. Einschleusen einer zweiten Abfrage/Aktualisierung (z.b. mit einem Semikolon). Test folgender Abfrage in der Konsole: MATCH (x:person) WHERE x.name = "x" OR "1" = "1" RETURN x UNION ALL CREATE (x:person {name : "Master"}) RETURN x //" RETURN x.geheimnis 55

64 6 Validierung am Beispiel der NoSQL-Datenbank Neo4j Ergebnis: Alle Knoten werden mit allen Attributen ausgegeben. Außerdem wurde eine neue Person mit dem Namen Master erzeugt. Bemerkung: Dieser Test zeigt, dass mit UNION auch weitere Schreibanforderungen eingeschleust werden können. Dies stellt ein erhebliches Sicherheitsrisiko dar. Angriff durchführbar Schema-Injection Zum Testen der Schema-Injection-Konzepte aus der Informationsbeschaffung müssen die gezeigten Beispielabfragen lediglich auf der Konsole des Admin- Webinterfaces ausprobiert und auf Fehler überprüft werden (vgl. Query-Injection). 1. Können ohne Einschränkungen neue Attribute/Werte hinzugefügt werden? Wenn nein, welche Einschränkungen gibt es? Test folgender Abfrage in der Konsole: MATCH (n:person { name: Sissi }) SET n.alter = 18 RETURN n Ergebnis: Ein neues Feld alter wurde mit dem Wert 18 hinzugefügt. Angriff durchführbar 2. Wie reagiert das System auf nicht eindeutige NoSQL-Queries? (Z.B. zwei Schreibanweisungen für ein Feld) Test folgender Abfrage in der Konsole: MATCH (n:person { name: Sissi }) SET n.alter = 18 SET n.alter = 36 RETURN n Ergebnis: Die zweite Aktualisierungsanfrage wurde übernommen. Neo4j lässt also nicht eindeutige Abfragen zu. Bemerkung: Dieses Verhalten stellt ein erhebliches Sicherheitsrisiko dar, da somit mittels einer Query-Injection auch Schreibabfragen modifiziert werden können, die vor der Injection-Position getätigt wurden. Angriff durchführbar JavaScript-Injection In der Informationsbeschaffung von Neo4j wurde festgestellt, dass bei Traversierungen JavaScript eingesetzt wird. Allerdings konnte nicht festgestellt werden, ob hier auch ein beliebiger Quellcode ausgeführt werden kann bzw., ob es Schutzmaßnahmen gibt. Dies soll nun im Rahmen der Testphase ermittelt werden, indem die in Kapitel vorgestellten Anwendungsszenarien getestet werden: 56

65 6.2 Sicherheitsanalyse von Neo4j Denial of Service (DOS) Analog zur Methodik in Kapitel wurde eine Beispielabfrage mit einer while(1)-schleife erstellt (siehe A.2.1 und A.2.2). Diese Abfrage startet eine Traversierungsanfrage beginnend mit dem Knoten mit der ID 8 bei allen Clusterinstanzen. Wird die HTML-Datei, die die Beispielabfrage enthält, in einem Browser geöffnet, so ist schnell zu erkennen, dass keine Antwort auf die Traversierungsanfragen zurückkommt. Die Datenbank antwortet nicht mehr oder nur noch sehr träge. Der DOS-Angriff war erfolgreich. Angriff durchführbar Dateisystem-Zugriff Zum Testen des Dateisystem-Zugriffs, wird die while(1)-schleife aus dem DOS-Angriff mit dem folgenden Quelltext ersetzt: 1 var dircontent = require( fs ).readdirsync(. ). tostring () ;true Beim Öffnen der HTML-Datei im Browser erscheint eine Warnmeldung mit dem Text Bad Request. Der JavaScript-Quelltext konnte also nicht ausgeführt werden. Angriff nicht durchführbar Bemerkung: Das true in der obigen Abfrage ist notwendig, da ein Wahrheitswert zurückgegeben werden muss. Aufbau eines Webservers Der Versuch einen Node.js-Server zu erstellen schlägt ebenso mit der Warnmeldung Bad Request fehl. Angriff nicht durchführbar Ausführen von Binärdateien Auch der Versuch Binärdateien auszuführen schlägt mit der Warnmeldung Bad Request fehl. Angriff nicht durchführbar Neben den oben genannten Anwendungsszenarien, schlägt auch der Test weiterer JavaScript-Module bzw. Klassen, wie z.b. XMLHTTPRequest, fehl. Dies lässt darauf schließen, dass keine Fremdskripte oder JavaScript-Klassen eingebunden werden können. Es kann allerdings versucht werden, den Quelltext des benötigten Skripts mit der Abfrage zusammenzulegen. Ein Blick auf den Quellcode von Neo4j zeigt, dass die zur Verfügung gestellten JavaScript-Klassen bzw. Module mittels einer Whitelist 12 beschränkt werden. 12 siehe neo4j/server/scripting/userscriptclasswhitelist.java, zuletzt abgerufen am

66 6 Validierung am Beispiel der NoSQL-Datenbank Neo4j Zusammenfassend kann gesagt werden, dass die Möglichkeiten für JavaScript- Injections zwar stark beschränkt sind, aber dennoch vereinzelt Angriffe, wie z.b. eine DOS-Attacke, möglich sind. Wie zu sehen ist können bis auf wenige Ausnahmen alle in der Informationsbeschaffung ermittelten Angriffsmöglichkeiten auf die direkte Datenbankschnittstelle angewendet werden. Schutzmaßnahmen existieren nur gegen JavaScript-Injections, wobei trotzdem eine DOS-Attacke möglich ist. Client-Bibliotheken auf Anwendbarkeit der Angriffe überprüfen Nun ist zu überprüfen, ob die ermittelten Angriffsmöglichkeiten auch durchführbar sind, wenn eine Client-Bibliothek verwendet wird. Im Rahmen dieser Arbeit soll die Bibliothek Neo4jPHP unter die Lupe genommen werden. Hierfür werden die Testapplikationen Personensuche und Traversierung (siehe Kapitel 6.1.2) genutzt, um ein reales Szenario zu simulieren. Query-Injection Zum Testen der Query-Injection-Angriffsmöglichkeiten wird die Testapplikation Personensuche verwendet. 1. Verwenden von Anführungszeichen ( oder ), um die Abfrage zu verändern. Eingabe des folgenden Ausdrucks in die Suchmaske: x" OR "1" = "1 Ergebnis: Alle Knoten werden ausgegeben. Angriff durchführbar 2. Verwenden eines Kommentars (z.b. mit // oder ), um die Abfrage zu verändern. Eingabe des folgenden Ausdrucks in die Suchmaske: x" OR "1" = "1" RETURN n // Ergebnis: Alle Knoten werden mit allen Attributen ausgegeben. Angriff durchführbar 3. Einschleusen einer zweiten Abfrage/Aktualisierung (z.b. mit einem Semikolon). Eingabe des folgenden Ausdrucks in die Suchmaske: x" OR "1" = "1" RETURN n UNION ALL CREATE (x:person {name : "Master"}) RETURN x // Ergebnis: Alle Knoten werden mit allen Attributen ausgegeben. Außerdem wurde eine neue Person mit dem Namen Master erzeugt. 58

67 6.2 Sicherheitsanalyse von Neo4j Angriff durchführbar Schema-Injection Zum Testen der Schema-Injection-Angriffsmöglichkeiten wird die Testapplikation Personensuche verwendet. 1. Können ohne Einschränkungen neue Attribute/Werte hinzugefügt werden? Wenn nein, welche Einschränkungen gibt es? Eingabe des folgenden Ausdrucks in die Suchmaske: x" OR "1" = "1" RETURN n UNION ALL MATCH (n:person { name: Sissi }) SET n.alter = 18 RETURN n // Ergebnis: Ein neues Feld alter wurde mit dem Wert 18 hinzugefügt. Des Weiteren werden alle anderen Knoten ausgegeben. Angriff durchführbar 2. Wie reagiert das System auf nicht eindeutige NoSQL-Queries? (Z.B. zwei Schreibanweisungen für ein Feld) Eingabe des folgenden Ausdrucks in die Suchmaske: x" OR "1" = "1" RETURN n UNION ALL MATCH (n:person { name: Sissi }) SET n.alter = 18 SET n.alter = 36 RETURN n // Ergebnis: Die zweite Aktualisierungsanfrage wurde übernommen. Neo4j-PHP lässt also nicht eindeutige Abfragen zu. Angriff durchführbar JavaScript-Injection Es wurde eine JavaScript-Injection-Angriffsmöglichkeit ermittelt: Es kann über Traversierungsanfragen JavaScript-Quelltext eingeschleust werden. Hiermit kann eine DOS-Attacke gestartet werden. Zum Testen der JavaScript-DOS-Attacke wird die Testapplikation Personensuche verwendet. Eingabe des folgenden Ausdrucks in die Suchmaske: sissi ) ; while(true) ; // Ergebnis: Es wird kein Resultat zurückgegeben. Die Neo4j-Instanz auf dem Port 7474 antwortet nur noch sehr langsam, d.h. die DOS-Attacke ist geglückt. 59

68 6 Validierung am Beispiel der NoSQL-Datenbank Neo4j Angriff durchführbar Diese Tests zeigen, dass auch mittels Neo4jPHP die gezeigten Angriffe angewendet werden können. Allerdings ist zu erwähnen, dass die Implementierung der Applikation Personensuche die Parameter direkt und ohne Überprüfung in das Statement einfügt. Neo4jPHP bietet allerdings auch die Möglichkeit an, die Parameter, ähnlich wie bei den Prepared Statements von SQL, einzufügen. Werden auf diese Art Abfragen formuliert, so sind die gezeigten Query- sowie Schema-Injections nicht möglich. Ein derartiges Schutzkonzept gibt es allerdings nicht für die gezeigte JavaScript- Injection. Testen der Kryptographie Bezüglich der Kryptographie müssen sowohl die Datenverbindungen als auch die Daten/Backups sowie Benutzerpasswörter überprüft werden: Testen der Kryptographie der Datenverbindungen Aus der Informationsbeschaffung (siehe Kapitel 6.2.1) geht bereits hervor, dass die Verbindungen zwischen den Klienten und der Datenbank optional mittels HTTPS verschlüsselt werden können. Zu überprüfen ist allerdings noch, ob die Verbindungen zwischen den Datenbankinstanzen verschlüsselt sind. Um dies herauszufinden, muss der Netzwerkverkehr zwischen den Neo4j-Instanzen z.b. mittels Wireshark aufgezeichnet und analysiert werden. Aus einer Aufzeichnung des Netzwerkverkehrs geht hervor, dass die Pakete zwischen den Neo4j-Instanzen nicht verschlüsselt sind. Dies kann daran erkannt werden, da als Protokoll lediglich TCP erkannt wird sowie die Daten der Pakete die Syntax eines serialisierten Java-Objekts aufweisen, was beispielsweise an folgender HeartbeatMessage erkannt werden learnedt??27t??tot??cluster:// :5002t??instance idt??3t??conversation idt??2/24#t??created byt??2t??fromt??cluster :// :5003x~r??5org.neo4j.cluster.protocol.heartbeat.HeartbeatMessage???????????xr???java.lang.Enum???????????xpt??i_am_alivesr??Corg.neo4j.cluster. protocol.heartbeat.heartbeatmessageiamalivestatexpsr???org.neo4j.cluster. InstanceIdxpw?????x Diese serialisierte Java-Objekte können sehr leicht deserialisiert werden, da der Quelltext von Neo4j quelloffen ist und somit genügend Details für eine Deserialisierung enthält. Ein Blick auf den Quellcode verrät zudem, dass alle weiteren Synchronisierungspakete die Java-Objektserialisierung verwenden Testen der Kryptographie der Daten/Backups und Benutzerpasswörter 60

69 6.2 Sicherheitsanalyse von Neo4j In der Informationsbeschaffung (siehe Kapitel 6.2.1) wurde bereits festgestellt, dass die Daten und Backups von Neo4j nicht ausreichend geschützt sind. Mit diesen kann sehr einfach eine neue Neo4j-Instanz aufgesetzt werden, die alle Daten offenlegt. Wie hierbei vorzugehen ist, wird in Kapitel 24 der Dokumentation von Neo4j 13 beschrieben und soll deshalb an dieser Stelle nicht näher erläutert werden. Da Neo4j außerdem keine Authentifizierung anbietet, ist eine Überprüfung der Kryptographie der Benutzerpasswörter ebenso hinfällig Risikobewertung In der Informationsbeschaffung und der Testphase wurden einige Schwachstellen identifiziert, die in diesem Abschnitt anhand des Risikos bewertet werden sollen. Schwache Standardkonfiguration 1. Risikoidentifizierung Die gefundene Schwachstelle Neo4j bietet standardmäßig keine Authentifizierung an. Dies bedeutet, dass ein Threat Agent auf die Datenbank zugreifen kann, ohne sich identifizieren zu müssen. Außerdem sind Details wie die Standardports, die URL der Adminweboberfläche und die öffentliche Zugänglichkeit von Neo4j-Cluster- Instanzen bekannt. Mit der Standardkonfiguration eines Neo4j-Clusters kann ein Thread Agent außerhalb des Netzwerks die gesamte Datenbank übernehmen. Falls eine einzelne Instanz für das Neo4j-System verwendet wird, so kann ein Thread Agent innerhalb des Netzwerks die Datenbank infiltrieren. Der Angriff zum Ausnutzen der Schwachstelle Über die Adminweboberfläche kann auf alle Daten der Datenbank zugegriffen werden. Möglicher worst-case Thread Agent Konkurrierende Unternehmen bzw. nicht spezifische Agents (wie z.b. Computerviren) Auswirkungen eines erfolgreichen Angriffs auf das Unternehmen Starker finanzieller Verlust durch Offenlegung von Geheimnissen oder auch der Lahmlegung der Datenbank. 2. Bestimmung der Eintrittswahrscheinlichkeit Threat Agent-Faktoren 13 siehe zuletzt abgerufen am

70 6 Validierung am Beispiel der NoSQL-Datenbank Neo4j a) Kompetenzlevel: (4) Mittlere technische Fähigkeiten b) Motiv: (1) Keine oder eine kleine Belohnung c) Möglichkeit: (7) Wenig Zugriff oder Ressourcen d) Größe: (9) Anonyme Internet-Benutzer Schwachstellen-Faktoren a) Schwierigkeitsgrad der Entdeckung: (9) Automatisierte Anwendungen denkbar b) Schwierigkeitsgrad des Ausnutzens: (9) Automatisierte Anwendungen denkbar c) Bekanntheit: (6) Unübersehbar d) Angriffsentdeckung: (8) Protokolliert ohne Begutachtung 3. Bestimmung der Auswirkung Faktoren mit technischen Auswirkungen a) Vertraulichkeitsverlust: (7) Sehr viele kritische Daten b) Integritätsverlust: (7) Sehr viele Daten ernsthaft beschädigt c) Verfügbarkeitsverlust: (7) Sehr viele Primärdienste sind unterbrochen d) Verlust der Rechenschaft: (9) Komplett anonym 4. Ermitteln des Ausmaßes des Risikos Um das Risiko zu bestimmen, muss die Eintrittswahrscheinlichkeit sowie die Auswirkung anhand der ermittelten Werte bestimmt werden. Hierfür muss laut Kapitel in einem ersten Schritt der Durchschnitt der Werte gebildet werden und diese dann anschließend in die Klassen GERING (0 bis <3), MITTEL (3 bis <6) und HOCH (6 bis 9) eingeordnet werden. Ist dies erfolgt, so kann anhand Tabelle 5.3 das resultierende Risiko abgelesen werden. a) Durchschnittliche Eintrittswahrscheinlichkeit: 6,625 HOCH b) Durchschnittliche Auswirkung: 7,5 HOCH c) Resultierendes Risiko: Kritisch (49,6875) Query-Injection und Schema-Injection-Angriffe 1. Risikoidentifizierung Die gefundene Schwachstelle Es wurden Query-Injection sowie Schema-Injection-Angriffe ermittelt, die es ermöglichen, eine Datenbankabfrage zu modifizieren. Hiermit können ohne direkten Datenbankzugriff sowohl Daten gelesen als auch geändert werden, 62

71 6.2 Sicherheitsanalyse von Neo4j sofern die Applikation keine Schutzmaßnahmen gegen diese Schwachstelle eingebaut hat. Der Angriff zum Ausnutzen der Schwachstelle Die auf Neo4j zugreifende Applikation muss auf Formulare überprüft werden, die nach Absenden eine Cypher-Abfrage auslösen. Ist ein derartiges Formular gefunden, so kann anhand der gezeigten Injection-Möglichkeiten überprüft werden, ob dieses anfällig für Query- oder Schema-Injections ist. Möglicher worst-case Thread Agent Konkurrierende Unternehmen bzw. nicht spezifische Agents (wie z.b. Computerviren) Auswirkungen eines erfolgreichen Angriffs auf das Unternehmen Starker finanzieller Verlust durch Offenlegung von Geheimnissen oder auch der Lahmlegung des Systems. 2. Bestimmung der Eintrittswahrscheinlichkeit Threat Agent-Faktoren a) Kompetenzlevel: (9) Penetrationtest-Fähigkeiten b) Motiv: (4) Mögliche Belohnung c) Möglichkeit: (7) Wenig Zugriff oder Ressourcen d) Größe: (9) Anonyme Internet-Benutzer Schwachstellen-Faktoren a) Schwierigkeitsgrad der Entdeckung: (9) Automatisierte Anwendungen denkbar b) Schwierigkeitsgrad des Ausnutzens: (5) Einfach c) Bekanntheit: (6) Unübersehbar d) Angriffsentdeckung: (8) Protokolliert ohne Begutachtung 3. Bestimmung der Auswirkung Faktoren mit technischen Auswirkungen a) Vertraulichkeitsverlust: (7) Sehr viele kritische Daten b) Integritätsverlust: (7) Sehr viele Daten ernsthaft beschädigt c) Verfügbarkeitsverlust: (7) Sehr viele Primärdienste sind unterbrochen d) Verlust der Rechenschaft: (9) Komplett anonym 4. Ermitteln des Ausmaßes des Risikos a) Durchschnittliche Eintrittswahrscheinlichkeit: 7,125 HOCH b) Durchschnittliche Auswirkung: 7,5 HOCH 63

72 6 Validierung am Beispiel der NoSQL-Datenbank Neo4j c) Resultierendes Risiko: Kritisch (53,4375) JavaScript-Injection: DOS-Angriff 1. Risikoidentifizierung Die gefundene Schwachstelle Es wurde ein JavaScript-Injection-Angriff identifiziert, der es ermöglicht die Neo4j-Datenbank lahmzulegen, sofern keine Schutzmaßnahmen hiergegen eingebaut sind. Der Angriff zum Ausnutzen der Schwachstelle Die auf Neo4j zugreifende Applikation muss auf Formulare überprüft werden, die nach Absenden eine Traversierungs-Abfrage auslösen. Ist ein derartiges Formular gefunden, so kann anhand des gezeigten JavaScript-Injection- Angriffs überprüft werden, ob das Formular anfällig für diesen Angriff ist. Möglicher worst-case Thread Agent Konkurrierende Unternehmen bzw. nicht spezifische Agents (wie z.b. Computerviren) Auswirkungen eines erfolgreichen Angriffs auf das Unternehmen Starker finanzieller Verlust durch Lahmlegung der Datenbank. 2. Bestimmung der Eintrittswahrscheinlichkeit Threat Agent-Faktoren a) Kompetenzlevel: (9) Penetrationtest-Fähigkeiten b) Motiv: (4) Mögliche Belohnung c) Möglichkeit: (7) Wenig Zugriff oder Ressourcen d) Größe: (9) Anonyme Internet-Benutzer Schwachstellen-Faktoren a) Schwierigkeitsgrad der Entdeckung: (9) Automatisierte Anwendungen denkbar b) Schwierigkeitsgrad des Ausnutzens: (3) Schwer c) Bekanntheit: (6) Unübersehbar d) Angriffsentdeckung: (8) Protokolliert ohne Begutachtung 3. Bestimmung der Auswirkung Faktoren mit technischen Auswirkungen a) Vertraulichkeitsverlust: (0) Kein Verlust b) Integritätsverlust: (0) Kein Verlust 64

73 6.2 Sicherheitsanalyse von Neo4j c) Verfügbarkeitsverlust: (9) Alle Dienste sind komplett nicht verfügbar d) Verlust der Rechenschaft: (9) Komplett anonym 4. Ermitteln des Ausmaßes des Risikos a) Durchschnittliche Eintrittswahrscheinlichkeit: 7,125 HOCH b) Durchschnittliche Auswirkung: 4,5 MITTEL c) Resultierendes Risiko: Hoch (32,0625) Nicht ausreichende Verschlüsselung der Kommunikation 1. Risikoidentifizierung Die gefundene Schwachstelle Es wurde ermittelt, dass Neo4j zwar die Kommunikation zwischen Client und Server verschlüsseln kann, dies aber nicht die Standardeinstellung ist. Des Weiteren ist die Kommunikation zwischen den Neo4j-Instanzen nicht verschlüsselt. Dies ermöglicht das Mitlesen der Nachrichten zwischen den Neo4j-Instanzen. Falls die Client-Server-Kommunikation nicht verschlüsselt ist, kann auch diese mitgelesen werden. Die Bedingung hierfür ist, dass der Threat Agent Zugriff auf den Netzwerkverkehr bzw. einen Ausschnitt von diesem hat. Der Angriff zum Ausnutzen der Schwachstelle Mittels des Programms Wireshark können die versendeten Netzwerkpakete abgefangen und analysiert werden. Möglicher worst-case Thread Agent Konkurrierende Unternehmen Auswirkungen eines erfolgreichen Angriffs auf das Unternehmen Starker finanzieller Verlust durch Offenlegung von Geheimnissen. 2. Bestimmung der Eintrittswahrscheinlichkeit Threat Agent-Faktoren a) Kompetenzlevel: (4) Mittlere technische Fähigkeiten b) Motiv: (4) Mögliche Belohnung c) Möglichkeit: (4) Zugriff auf Netzwerkverkehr d) Größe: (4) Intranet-Benutzer Schwachstellen-Faktoren a) Schwierigkeitsgrad der Entdeckung: (7) Einfach b) Schwierigkeitsgrad des Ausnutzens: (3) Schwer 65

74 6 Validierung am Beispiel der NoSQL-Datenbank Neo4j c) Bekanntheit: (4) Versteckt d) Angriffsentdeckung: (9) Nicht protokolliert 3. Bestimmung der Auswirkung Faktoren mit technischen Auswirkungen a) Vertraulichkeitsverlust: (7) Sehr viele kritische Daten b) Integritätsverlust: (0) Kein Verlust c) Verfügbarkeitsverlust: (0) Kein Verlust d) Verlust der Rechenschaft: (9) Komplett anonym 4. Ermitteln des Ausmaßes des Risikos a) Durchschnittliche Eintrittswahrscheinlichkeit: 4,875 MITTEL b) Durchschnittliche Auswirkung: 4 MITTEL c) Resultierendes Risiko: Mittel (19,5) Fehlende Verschlüsselung der Backups/Daten 1. Risikoidentifizierung Die gefundene Schwachstelle Die Backups bzw. Daten von Neo4j sind nicht ausreichend verschlüsselt. Es kann eine neue Datenbank mit einem vorhandenen Backup/Daten aufgesetzt werden, was alle Inhalte der Datenbank offenlegt. Die Voraussetzung hierfür ist, dass diese Daten vorliegen. Der Angriff zum Ausnutzen der Schwachstelle Das Vorgehen zum Einspielen eines Backups aus der Dokumentation von Neo4j 14 kann zum Ausnutzen der Schwachstelle verwendet werden. Möglicher worst-case Thread Agent Systemadministratoren Auswirkungen eines erfolgreichen Angriffs auf das Unternehmen Starker finanzieller Verlust durch Offenlegung von Geheimnissen. 2. Bestimmung der Eintrittswahrscheinlichkeit Threat Agent-Faktoren a) Kompetenzlevel: (6) Netzwerk- und Programmierfähigkeiten b) Motiv: (9) Hohe Belohnung c) Möglichkeit: (4) Zugriff auf Netzwerkverkehr 14 siehe zuletzt abgerufen am

75 6.3 Ergebnisse der Sicherheitsanalyse von Neo4j d) Größe: (4) Zugriff auf Backups/Daten Schwachstellen-Faktoren a) Schwierigkeitsgrad der Entdeckung: (7) Einfach b) Schwierigkeitsgrad des Ausnutzens: (5) Einfach c) Bekanntheit: (6) Unübersehbar d) Angriffsentdeckung: (9) Nicht protokolliert 3. Bestimmung der Auswirkung Faktoren mit technischen Auswirkungen a) Vertraulichkeitsverlust: (9) Alle Daten b) Integritätsverlust: (0) Kein Verlust c) Verfügbarkeitsverlust: (0) Kein Verlust d) Verlust der Rechenschaft: (9) Komplett anonym 4. Ermitteln des Ausmaßes des Risikos a) Durchschnittliche Eintrittswahrscheinlichkeit: 6,25 HOCH b) Durchschnittliche Auswirkung: 4,5 MITTEL c) Resultierendes Risiko: Hoch (28,125) 6.3 Ergebnisse der Sicherheitsanalyse von Neo4j In diesem Kapitel wurden zahlreiche Sicherheitsdefizite von Neo4j aufgedeckt, die keinesfalls zu unterschätzen sind: Es wurde festgestellt, dass Neo4j eine sehr schwache Standardkonfiguration besitzt. Die Kombination mehrerer fehlender Sicherheitseinstellungen ermöglicht einem Angreifer sowohl das Auslesen und Ändern aller Daten der Datenbank als auch das Lahmlegen des Systems. Dieses Sicherheitsdefizit wurde als kritisch eingestuft. Des Weiteren wurden sowohl Query-Injection als auch Schema-Injection-Möglichkeiten ermittelt. Mit diesen können gegebene Abfragen beliebig modifiziert und somit ansonsten nicht zugängliche Daten gelesen und geändert werden. Dieses Sicherheitsdefizit wurde als hoch eingestuft. Eine weitere gefundene Sicherheitslücke ist, dass mittels einer JavaScript-Injection ein DOS-Angriff ausgeführt werden kann. In anderen Worten kann ein Threat Agent/- Penetration Tester somit eine Neo4j lahmlegen, sofern die Voraussetzungen dieser JavaScript-Injection erfüllt sind. Dieses Sicherheitsdefizit wurde als hoch eingestuft. Nicht zu vernachlässigen ist außerdem, dass die Kommunikation der Verbindungen von Neo4j nicht ausreichend verschlüsselt sind. Während der Datenverkehr zwischen den Neo4j-Instanzen überhaupt nicht gesichert sind, kann die Client-Server- 67

76 6 Validierung am Beispiel der NoSQL-Datenbank Neo4j Kommunikation optional verschlüsselt werden. Der Standard ist allerdings immer noch die unverschlüsselte Variante. Hat ein Angreifer Zugriff auf diese Netzwerkströme, so kann dieser alle Inhalte mitlesen. Dieses Sicherheitsdefizit wurde als mittel eingestuft. Das letzte ermittelte Sicherheitsdefizit ist die fehlende Verschlüsselung der Backups/- Daten. Es kann ohne Authentifizierung eine neue Neo4j-Instanz mit einem vorhandenen Backup/Daten erstellt werden, was zu einer vollständigen Offenlegung der Inhalte der Datenbank führt. Dieses Sicherheitsdefizit wurde als hoch eingestuft. Da alle ermittelten Sicherheitsdefizite ein hohes Risiko darstellen, sollte beim Einsatz von Neo4j darauf geachtet werden, diese so gut es geht einzudämmen. Die Neo4j- Datenbank sollte also nicht in der Standardkonfiguration eingesetzt werden. Außerdem muss seitens der Applikation sichergestellt werden, dass Query-, Schema- und JavaScript-Injections nicht mehr möglich sind. Zudem sollte immer auf eine verschlüsselte Client-Server-Kommunikation gesetzt werden und die Backups der Datenbank separat verschlüsselt werden. 68

77 7 Validierung am Beispiel der NoSQL-Datenbank CouchDB Abbildung 7.1: Logo der NoSQL-Datenbank CouchDB 1 In diesem Kapitel soll die Methodik zur Sicherheitsanalyse (siehe Kapitel 5) auf die NoSQL-Graphdatenbank CouchDB angewendet werden, um potentielle Sicherheitsdefizite aufzudecken und zu bewerten. Die Vorgehensweise hierfür entspricht derselben wie in Kapitel 6: Es wird in einem ersten Schritt eine kurze Einführung in CouchDB gegeben, um CouchDB von anderen NoSQL-Systemen abzugrenzen und dessen Funktionsweise vorzustellen. Hier wird außerdem aufgezeigt, wie die für die Sicherheitanalyse relevante Testinstanz von CouchDB aufgebaut und konfiguriert ist. In einem zweiten Schritt wird die Sicherheitsanalyse von CouchDB unter Verwendung der Methodik aus Kapitel 5 durchgeführt und vorgestellt. Abschließend werden die Ergebnisse der Sicherheitsanalyse von CouchDB wieder aufgegriffen und analysiert. 7.1 Einführung in CouchDB In diesem Abschnitt wird auf die Eigenschaften und die Funktionsweise von CouchDB eingegangen. Anschließend wird das für die Sicherheitsanalyse relevante Testsystem aufgezeigt. Abschließend wird demonstriert, wie bei CouchDB Daten eingefügt und abgefragt werden können. 1 Quelle: zuletzt abgerufen am

78 7 Validierung am Beispiel der NoSQL-Datenbank CouchDB Einordnung und Charakterisierung Die NoSQL-Datenbank CouchDB gehört der Kategorie der Dokumentendatenbanken an. Wie bereits in Kapitel erwähnt wurde, speichern diese Systeme ihre Daten als Dokumente ab, die aus JSON-Objekten bestehen. Dieser Datentyp ist schemafrei, es können also beliebig viele neue Attribute hinzugefügt werden [9]. Mithilfe sogenannter Views können Abfragen formuliert werden. Im Gegensatz zu relationalen Datenbanken setzt hier CouchDB allerdings auf das Map/Reduce-Konzept (siehe Abfragemöglichkeiten). Anders als bei relationalen Datenbanken, werden bei CouchDB nicht bei jedem View-Aufruf die geforderten Daten erneut abgefragt: Ist einmal eine View generiert, so werden dessen zugehörigen Ergebnisse stets aktuell gehalten. Wie Dokumente und Views generiert und verwendet werden können, wird in Kapitel aufgezeigt [9]. Da in der NoSQL-Welt viele weitere Dokumentendatenbanken existieren, soll nun CouchDB von den anderen Vertretern dieser Kategorie abgegrenzt werden. Hierfür werden die charakteristischen Eigenschaften von Kapitel wieder herangezogen. Konsistenz 1. Welches Konsistenzmodell (z.b. ACID oder BASE) wird verwendet? CouchDB verwendet BASE als Konsistenzmodell [9]. 2. Wie werden die Daten konsistent gehalten, wenn nur ein Server verwendet wird? Die Daten auf einem einzelnen Server sind immer konsistent (Local Consistency). Dies wird von CouchDB intern durch Transaktionen sichergestellt [9]. 3. Wie werden die Daten konsistent gehalten, wenn diese auf viele Server verteilt sind? CouchDB bietet eine inkrementelle Replikation an. Das bedeutet, dass nur Dokumente synchronisiert werden, die seit dem letzten Replikationsvorgang aktualisiert wurden. Da nicht unmittelbar nach einer Änderung die Synchronisierung gestartet wird, sind die Daten bei mehreren Servern eventuell konsistent (Eventual Consistency) [9]. Transaktionen 1. Werden Transaktionen bzw. transaktionsähnliche Mechanismen angeboten? Traditionelle Transaktionen wie bei relationalen Datenbanken werden von CouchDB nicht unterstützt. Es existieren aber Vorgehensweisen, wie kleine Transaktionen durchgeführt werden können [2]. 70

79 7.1 Einführung in CouchDB Verfügbarkeit 1. Bietet die Datenbank Replikation an? Es wird eine inkrementelle Replikation angeboten (siehe Konsistenz) [9]. 2. Wird Sharding unterstützt? Sharding bzw. Clustering kann mittels CouchDB Lounge realisiert werden. Hiermit können alle Daten auf verschiedene Server aufgeteilt und somit die Performance erhöht werden [9]. Abfragemöglichkeiten 1. Werden von der Datenbank Abfragesprachen angeboten? Wenn ja, wie mächtig sind diese? Abfragesprachen, wie z.b. Cypher von Neo4j oder SQL, werden von CouchDB nicht angeboten [9]. 2. Wie können Indizes erstellt werden? Abfragen werden bei CouchDB mittels Views realisiert. Eine View enthält sowohl eine Map als auch eine Reduce-Funktion, die jeweils in JavaScript formuliert sind [9]. Die Map-Funktion wird auf jedes existierende Dokument in CouchDB angewendet und filtert in der Regel die Dokumente, indem überprüft wird, ob bestimmte Felder existieren. Falls ein Dokument akzeptiert wird, wird ein Key/Value-Paar generiert. Das Ergebnis dieses Durchlaufs ist ein nach dem Key sortierter B-Baum (Index), der bei Änderungen stetig aktualisiert wird. Diese resultierende Baumstruktur kann hoch effizient durchsucht werden [9]. Die Reduce-Funktion ist optional. Diese wird auf dem von der Map-Funktion generierten B-Baum ausgeführt und reduziert die Ergebnismenge auf ein oder mehrere Werte [9]. 3. Wie können Abfragen ausgeführt werden und welche Konzepte werden hierfür verwendet? CouchDB bietet eine REST-API an, über die alle Datenbankoperationen durchgeführt werden können [9]. Außerdem existieren für alle gängigen Programmiersprachen Client-Bibliotheken, die entweder von CouchDB direkt oder von externen Anbietern bereitgestellt werden. All diese Implementierungen greifen über die REST-API-Schnittstelle auf die Datenbank zu [9]. Skalierung 1. Welche Möglichkeiten zur Skalierung werden angeboten? 71

80 7 Validierung am Beispiel der NoSQL-Datenbank CouchDB CouchDB bietet sowohl eine Replikation als auch Sharding/Clustering an. Indem die Daten auf viele Server verteilt werden (Clustering), kann die Performance sehr stark erhöht werden. Mittels Replikation kann zusätzlich die Lesegeschwindigkeit gesteigert werden und sichergestellt werden, dass bei einem Datenverlust Backupserver zur Verfügung stehen [9] Testaufbau Penetrationtester Personensuche Personenregistrierung personen personenreplikation PHP-Applikationen CouchDB Datenbanken Abbildung 7.2: Testaufbau CouchDB Wie in Abbildung 7.2 zu sehen ist, besteht das Testsystem aus einer CouchDB-Instanz mit zwei Datenbanken sowie zweier PHP-Applikationen. CouchDB wurde mit dem Paketmanager apt-get auf einem Ubuntu LTS System installiert und konfiguriert. Es wird die Version verwendet. Wie die Datenbanken sowie die Replikation erstellt wurden, wird in Kapitel beschrieben. Die CouchDB-Instanz verwendet den Port 5984 (Standardport). Über diesen können alle Datenbankoperationen durchgeführt werden. Des Weiteren beinhaltet das Testsystem zwei PHP-Webapplikationen, welche auf die CouchDB-Instanz zugreifen. Die Anwendung Personensuche generiert eine Suchmaske und zeigt die Ergebnisse der Suche in Form einer Tabelle an. Im Gegensatz zum Testaufbau von Neo4j (siehe Kapitel 6.1.2), beinhaltet das Testsystem von CouchDB eine Anwendung, die auch Daten schreiben kann: Die Applikation Personenregistrierung generiert ein Formular, mit dem neue Personen erstellt werden können. Diese wird im 72