Fingerprinting von Web Application Firewall-Filterregeln durch Timing-Seitenkanäle

Transkript

1 Fingerprinting von Web Application Firewall-Filterregeln durch Timing-Seitenkanäle Bachelorarbeit vorgelegt am Lehrstuhl für Praktische Informatik 1 Professor Dr.-Ing. Felix Freiling Universität Mannheim betreut von M.Sc. Sebastian Schinzel im Juni 2011 von Isabell Schmitt geboren in Erbach, Deutschland

2 Ehrenwörtliche Erklärung Ich versichere, dass ich die beiliegende Bachelorarbeit ohne Hilfe Dritter und ohne Benutzung anderer als der angegebenen Quellen und Hilfsmittel angefertigt und die den benutzten Quellen wörtlich oder inhaltlich entnommenen Stellen als solche kenntlich gemacht habe. Diese Arbeit hat in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen. Ich bin mir bewusst, dass eine falsche Erklärung rechtliche Folgen haben wird. Mannheim, den Unterschrift

3 Inhaltsverzeichnis Abbildungsverzeichnis Quellcodeverzeichnis Abkürzungsverzeichnis V VI VII 1. Einleitung 1 2. Grundlegende Begriffe Timing-Seitenkanäle Direkte Timing-Angriffe Cross-Site Timing-Angriffe Web Application Firewall ModSecurity PHPIDS Verwundbarkeiten von Web-Anwendungen SQL-Injection Cross-Site Scripting Directory Traversal Fingerprinting von WAF-Filterregeln durch Timing-Seitenkanäle Fingerprinting mit direkten Timing-Angriffen Definition von Zeichen und Zeichenketten Erkennen einer verwendeten WAF Ermitteln der Parameter Durchführung des Fingerprinting Auswertung der Messergebnisse Fingerprinting mit Cross-Site Timing-Angriffen Fingerprinting am Beispiel PHPBB Testumgebung Testaufbau verwendete Filterregeln verwendete Zeichen und Zeichenketten III

4 Inhaltsverzeichnis IV ermitteln der verwendeten Parameter Installation in der demilitarisierten Zone Installation auf dem Webserver PHPIDS Diskussion Aufwand und Probleme Ist diese Methode sinnvoll? Fazit 36 A. Anhang VIII A.1. Definition Zeichen und Zeichenketten VIII A.1.1. SQL-Injection VIII A.1.2. Cross-Site Scripting IX A.1.3. Directory Traversal X B. Anhang XII B.1. Output: Installation in der demilitarisierten Zone XII C. Anhang XIII C.1. Abgabe DVDs XIII Literaturverzeichnis XIV

5 Abbildungsverzeichnis 2.1. Ablauf direkter Timing-Angriff Ablauf Cross-Site Timing-Angriff Ablauf Web Application Firewall ModSecurity: Installation Reverse-Proxy ModSecurity: Installation auf dem Webserver Bibliothek PHPIDS eingebunden Timing-Seitenkanäle bei Verwendung einer WAF Unendliche Angriffsvariationen Erster Test: Relation Grenzwert Errechnung des Grenzwertes Graphische Ausgabe des Prototypen Testaufbau mit OVH Cloud Installation in der demilitarisierten Zone: Erster Test und Grenzwert Installation in der demilitarisierten Zone: Fingerprinting Zeitmessung Installation auf dem Webserver: Erster Test und Grenzwert Installation auf dem Webserver: Fingerprinting Zeitmessung PHPIDS: Erster Test und Grenzwert PHPIDS: Fingerprinting Zeitmessung B.1. Auszug Output SQL-Injection XII V

6 Quellcodeverzeichnis 2.1. Normaler SQL-Befehl SQL-Befehl mit SQL-Injection Messung der Webserver Antwortzeit VI

7 Abkürzungsverzeichnis CPU HTML IP PHP RDTSC SQL SSD URL WAF XSS Central Processing Unit Hypertext Markup Language Internet Protocol PHP Hypertext Preprocessor Read Time-Stamp Counter Structured Query Language Solid-State-Drive Uniform Resource Locator Web Application Firewall Cross-Site Scripting VII

8 1. Einleitung Zum Schutz einer Web-Anwendung kann eine Web Application Firewall (WAF) verwendet werden. Die Schwachstellen einer Web-Anwendung sollen durch eine WAF vor Angriffen geschützt werden. Doch schützt eine WAF die Web-Anwendung wirklich vor Angriffen aus dem Internet? Bei der Nutzung von Web-Anwendungen wird eine Verbindung zwischen dem Benutzer und dem Webserver hergestellt. Der Benutzer kann beispielsweise über Eingabefelder Daten hinzufügen oder sich in Mitgliederbereiche anmelden. Unter anderem wäre es auch möglich, dass ein Benutzer Daten über die Web-Anwendung auf den Webserver hochlädt und dort verarbeiten lässt. Diese Interaktion zwischen Webserver und Benutzer kann zu einigen Sicherheitsproblemen führen. Ein böswilliger Angreifer kann beispielsweise durch Eingabefelder oder durch Manipulation der URL, Angriffe auf die Datenbank im Hintergrund der Web-Anwendung vornehmen. Wenn nun dort Schwachstellen vorhanden sind, kann ein Angreifer erheblichen Schaden verursachen. Um solche nicht legitimen Eingaben zu verhindern, kann eine WAF verwendet werden. Hier werden die Eingaben geprüft bevor sie an die Web-Anwendung weitergeleitet werden. Mit Hilfe von Filterregeln entscheidet die WAF, welche Zeichen und Zeichenketten in den Anfragen erlaubt sind, um sofort nicht legitime Anfragen auszufiltern. Deutet die WAF eine Anfrage als unzulässig, so blockiert sie die Anfrage und gibt eine Fehlermeldung an den Anfragenden zurück. Oftmals werden sogenannte White Lists verwendet, wobei es sich um eine Festlegung aller legitimen Ausdrücke für ein Eingabefeld handelt. Eine White List besteht somit nur aus legitimen Ausdrücken. Sind die Zeichen der Eingabe in der Liste vorhanden, so gilt die Eingabe als legitime Anfrage. Im Gegensatz dazu, gibt es auch eine Black List, bei der es sich um eine Auflistung von nicht legitimen Ausdrücken handelt. Eine Auflistung von nicht legitimen Ausdrücken ist aufwendiger, als die Auflistung von legitimen Ausdrücken. Man benötigt das Wissen über verschiedene Angriffsvarianten und es ist unmöglich alle abzudecken, da man dafür alle kennen müsste. Es gibt unendlich viele Angriffsvarianten und mit Hilfe einiger Tricks können Angriffe verschleiert werden. Zum Beispiel können einfache Leerzeichen den Angriff abändern, so dass die Black List diesen Angriff nicht mehr enthält, obwohl er semantisch gleich ist. Dabei können unendlich viele Leerzeichen eingefügt werden. Eine Gefahr bei White Lists stellt dagegen das Zulassen von bestimmten Zeichen dar, die der Benutzer benötigt, die aber auch für einen Angriff verwendet 1

9 1. Einleitung 2 werden könnten. Die Abdeckung aller Angriffsvarianten ist somit fast unmöglich und Sicherheitslücken nicht ausgeschlossen. Die WAF-Filterregeln sollen Angriffe auf Schwachstellen in der Web-Anwendung verhindern. Deshalb muss der Angreifer nach Lücken in den WAF-Filterregeln suchen, über die er die Schwachstellen der Web-Anwendung angreifen kann. Eine Schwachstelle in den WAF-Filterregeln ist somit eine Lücke, die ausgenutzt werden kann, um die Web- Anwendung im Hintergrund der WAF anzugreifen. Die Schwierigkeit liegt dabei darin, die unbekannten WAF-Filterregeln auf Lücken zu durchsuchen. Um die Filterregeln für den Benutzer geheim zu halten, sollten sich die Fehlermeldungen von einer WAF und der durch diese geschützte Web-Anwendung bis aufs Detail gleichen. Somit wird das Umgehen der Filterregeln für einen Angreifer erschwert, da dieser über die Fehlermeldung keinen Rückschluss auf die Filterregeln erlangen kann. Der Angreifer weiß nicht, ob die Eingabe schon in der WAF blockiert wurde oder bis zur Web-Anwendung gelangt ist. Sollten verschiedene Fehlermeldungen erscheinen, so kann der Angreifer erkennen, wann die WAF eine Anfrage blockiert und wann die Web-Anwendung einen Fehler meldet. Eine typische Fehlermeldung für eine blockierende WAF ist die Forbidden 403 Fehlermeldung. Eine in der Web-Anwendung generierte Fehlermeldung dagegen, könnte die 500 Internal Server Error sein. Somit ist es wesentlich schwieriger bei gleichen Fehlermeldungen die Filterregeln herauszufinden und eine durch eine WAF gesicherte Web-Anwendung anzugreifen. Ein Fingerprinting der Filterregeln kann zeigen, welche Angriffe tatsächlich durchgeführt werden können und welche nicht. Ein Fingerprinting zeigt, welche Filterregeln existieren und welche Angriffe durch die Filterregeln nicht blockiert werden. Darüber hinaus gibt er Aufschluss über die Sicherheit der eigenen Web-Anwendung. Doch ist es schwierig über gleiche Fehlermeldungen Rückschluss auf die Herkunft der Fehlermeldungen zu erlangen. Die Fehlermeldungen können allerdings über ihre Ladezeit verraten woher sie stammen. Eine Fehlermeldung der WAF benötigt weniger Ladezeit als eine Fehlermeldung der Web-Anwendung. Die WAF muss die Eingaben des Benutzers auf valide Anfragen prüfen. Sobald ein Zeichen der Anfrage nicht in den WAF-Filterregeln erlaubt wurde, gibt die WAF eine Fehlermeldung aus und blockiert die Anfrage. Wenn alle Zeichen anhand der Filterregeln valide sind, bekommt die Web-Anwendung die Eingabe übermittelt. Die Web-Anwendung startet dann eigene Überprüfungen auf Richtigkeit. Sollten die Anfragen durch die Validierung der Web-Anwendung gelangen und trotzdem einen Fehler auslösen, wird eine der WAF Fehlermeldung gleichende Fehlermeldung ausgegeben. Doch wird bei der Ausgabe einer Fehlermeldung von der Web-Anwendung wesentlich mehr Zeit benötigt, da die Prüfung der WAF-Filterregeln ebenfalls ausgeführt werden müssen plus eventuell vorhandene Prüfungen der Web-Anwendung auf Richtigkeit. Diese Zeitunterschiede werden als Timing-Seitenkanal bezeichnet. Der Timing-Seitenkanal

10 1. Einleitung 3 wird in dieser Bachelorarbeit für das Fingerprinting der WAF-Filterregeln ausgenutzt. Die Kommunikation zwischen Benutzer und Web-Anwendung hinterlässt wichtige Informationen, die nur gemessen werden müssen. Die Antwortzeit des Webservers gibt Rückschluss darüber, ob die Fehlermeldung von der WAF oder von der Web-Anwendung generiert wurde. Der Zeitunterschied ist mess- und auswertbar. Mit Hilfe der Ergebnisse aus den Zeitmessungen kann herausgefunden werden, welche Anfragen in der WAF blockiert werden und welche nicht. Das Thema dieser Bachelorarbeit ist es, eine Methode zu entwickeln, die es ermöglicht, die Filterregeln einer WAF zu ertasten und ein Bild dieser Filterregeln herzustellen. Ein Angreifer kann damit gezielt Schwachstellen der WAF-Filterregeln finden. Der Bekanntheitsgrad von Timing-Seitenkanälen soll mit Hilfe dieser Bachelorarbeit erhöht werden, denn es handelt sich, um eine eher unbekannte Methode an vertrauliche Informationen zu gelangen. Vor allem aber können Angreifer mit dieser Methode gezielter nach Schwachstellen in den Filterregeln einer WAF suchen. Während der Bachelorarbeit soll ein Prototyp entstehen, der mit Hilfe von Timing- Seitenkanälen ein Fingerprinting von Filterregeln einer WAF erstellt. Darüber hinaus sollen die, durch die WAF nicht blockierten, möglichen Angriffsvarianten bildlich dargestellt werden. Um den Rahmen dieser Bachelorarbeit nicht zu sprengen, wird sich dabei auf die beiden sehr bekannten Angriffsarten SQL-Injection und Cross-Site Scripting (XSS) bezogen. Sowie auf die Angriffsart des Directory Traversal, welche schwerwiegende Folgen haben kann, wie zum Beispiel Passwortklau. Für die Überprüfung der Filterregeln werden Zeichen und Zeichenketten, die für die drei Angriffsarten benötigt werden, auf die einzelnen Parameter einer Web-Anwendung angesetzt. Dabei ist es so gut wie unmöglich alle Angriffe dieser drei Angriffsarten darzustellen. Es soll lediglich eine gute Auswahl bekannterer Angriffe getestet werden. Im nachfolgenden Kapitel sollen grundlegende Begriffe vorgestellt werden, die den Einstieg in die Bachelorarbeit erleichtern sollen. In Kapitel 3 werden die zwei Angriffsarten des Timing-Angriffs auf WAF-Filterregeln vorgestellt. Dabei wird der Ablauf des Fingerprinting erläutert. Diesem Ablauf entsprechend wird eine Praxis Test in Kapitel 4 durchgeführt. Bei diesem Praxis Test wird der Prototyp an der bekannten Web-Anwendung phpbb getestet. Die Testumgebung und die Messergebnisse der einzelnen Tests werden in diesem Kapitel vorgestellt. Zum Abschluss wird in Kapitel 5 diskutiert, wie praktikabel die Methode über Timing-Seitenkanäle WAF-Filterregeln abzutasten wirklich ist. In Kapitel 6 wird ein kleines Fazit gezogen.

11 2. Grundlegende Begriffe Dieses Kapitel soll den Einstieg in das Thema Timing-Seitenkanäle erleichtern und einige sehr bekannte Begriffe in einem neuen Licht erscheinen lassen. Die Möglichkeit über Timing-Seitenkanäle an vertrauliche Informationen zu gelangen, ist noch weitgehend unbekannt und stellt eine neue Herausforderung der IT-Sicherheitstechnik dar. Zum besseren Verständnis werden hier alle nötigen Begriffe kurz beschrieben. Als erstes wird hier der Timing-Seitenkanal erklärt und zwei Arten von Timing-Angriffe vorgestellt. Beide sind für das Fingerprinting von WAF-Filterregeln von Bedeutung. Danach wird die WAF ModSecurity und die Web-Anwendungs Bibliothek PHPIDS kurz vorgestellt. Für das Fingerprinting werden in der Bachelorarbeit drei verschiedene Angriffsarten auf Web-Anwendungen verwendet, SQL-Injection, XSS und Directory Traversal, diese werden ebenfalls in diesem Kapitel kurz beschrieben Timing-Seitenkanäle Für das Fingerprinting der WAF-Filterregeln wird in dieser Bachelorarbeit der Timing- Seitenkanal ausgenutzt. Das Erlangen von vertraulichen Informationen über Hintertüren wird in der Fachsprache als Angriff über einen Seitenkanal (Bortz und Boneh 2007) bezeichnet. Bei der Ausnutzung eines Seitenkanals wird kein direkter Angriff auf die Ressourcen der Web-Anwendung ausgeführt. Es ist möglich, über das Messen von Antwortzeiten oder das Messen von dem Stromverbrauch eines Rechners auf vertrauliche Informationen zu schließen. Das Messen von Antwortzeiten eines Webservers wird als Timing-Angriff bezeichnet. Sobald sich ein Unterschied in den Antwortzeiten eines Webservers ergibt, können Timing-Seitenkanäle ausgenutzt werden. Die gemessene Differenz gibt Rückschluss auf die im Hintergrund ablaufenden Tätigkeiten des Webservers. Dabei kann es sich um die Übermittlung, Analyse oder Speicherung von Daten handeln. Diese Tätigkeiten geben Daten preis, mit denen man auf vertrauliche Informationen schließen kann. Die Gefährlichkeit von Seitenkanälen ist noch nicht bei allen Webseiten-Entwicklern bekannt. Der häufigste genannte Grund dafür ist, dass Timing-Seitenkanäle bisher noch keinen hohen Bekanntheitsgrad aufweisen können (Bortz und Boneh 2007). Für das Fingerprinting von WAF-Filterregeln sind zwei Angriffsarten von Bedeutung. Eine direkte Anfrage an den Webserver wird als direkter Timing-Angriff bezeichnet. Dabei wird die Antwortzeit des Webservers gemessen. Bei dem Fingerprinting von WAF-Filterregeln 4

12 2.1. Timing-Seitenkanäle 5 werden Angriffe gesendet, die in den WAF Log-Dateien mit zugehöriger IP-Adresse des Angreifers vermerkt werden. Um dies zu verhindern kann es nun von Vorteil sein, statt dem direkten Timing-Angriff, die zweite Angriffsart, den Cross-Site Timing-Angriff zu verwenden. Hierbei wird der eigentliche Angriff unsichtbar für den anzugreifenden Benutzer auf einer Webseite positioniert. Der Benutzer bekommt nicht mit, wenn diese Webseite beim Besuch, die Antwortzeiten einer anderen offenen Webseite misst. Somit kann die Herkunft des Timing-Angriffes beim Fingerprinting von WAF-Filterregeln verschleiert werden Direkte Timing-Angriffe Der direkte Timing-Angriff (Bortz und Boneh 2007) sendet eine direkte Anfrage an die anzugreifende Webseite. Der Angreifer entsendet die Anfrage und misst die Antwortzeit des Webservers. Dafür muss er nur die Zeit oder die CPU Takte vor und nach der Anfrage messen. Die Differenz zwischen Anfrage und Antwort des Webservers kann nun Daten preisgeben. Der Angreifer ist dabei flexibel und kann jegliche Variation von Anfrage an den Webserver senden. Damit kann der Angreifer Unterschiede zwischen normalen Anfragen und von dem Webserver unerwarteten Anfragen ausfindig machen. Die Zeitunterschiede können dabei beachtlich groß werden und sind abhängig von den Tätigkeiten, die während einer Anfragenbearbeitung ablaufen. Durch diese Zeitunterschiede können nun auf Tätigkeiten geschlossen werden, die Rückschlüsse auf die im Hintergrund verarbeiteten Daten ziehen lassen. Somit wird es möglich, durch Zeitmessungen an vertrauliche Informationen zu gelangen, die eigentlich nicht so einfach zu erlangen sind. Direkte Timing-Angriffe auswerten Die Auswertung von direkten Timing-Angriffen kann erschwert sein durch ein Rauschen (Bortz und Boneh 2007) in den Messungen. Dieses Rauschen entsteht, wenn der Webserver verschieden lange für eine Antwort braucht. Zu verschiedenen Uhrzeiten kann der Webserver unterschiedliche Antwortzeiten bei der Bearbeitung von Anfragen in Anspruch nehmen. In erster Linie sind dafür Transportzeiten von Paketen im Netzwerk oder Paketverlust verantwortlich. Darüber hinaus kann die Anzahl der Anfragen an den Webserver im gleichen Moment eine Rolle spielen. Bei der Bearbeitung von vielen Anfragen gleichzeitig, wird die Bearbeitung der Anfragen verzögert. Aber das Rauschen lässt sich durch viele direkte Anfragen herausfiltern und es sollten sich, sobald es sich um einen Timing- Seitenkanal handelt deutliche Sachverhalte erschließen lassen. Die durchschnittliche Varianz der Antwortzeiten kann bestimmt werden, welche abhängig von dem stets additiven Rauschen ist (Bortz und Boneh 2007).

13 2.1. Timing-Seitenkanäle 6 Ablauf von direkten Timing-Angriffen Es gibt viele für direkte Timing-Angriffe anfällige Web-Anwendungen. So kann die Anzahl von für den Benutzer versteckte Dateien geschätzt werden oder die Richtigkeit von Variablen (Bortz und Boneh 2007) überprüft werden. Der Ablauf des direkten Timing-Angriffes zur Variablen Prüfung unterscheidet sich im Ablauf kaum von dem in späteren Kapiteln beschriebenen Fingerprintings durch Timing-Seitenkanäle. Am Beispiel eines normalen Anmeldevorgangs soll der wesentliche Ablauf des direkten Timing-Angriffes erläutert werden. Bei dem Anmeldevorgang zu einer Web-Anwendung werden Fehlermeldungen dafür Abb. 2.1.: Ablauf direkter Timing-Angriff. verwendet, um dem Benutzer den momentan aufgetretenen Fehler anzuzeigen. Damit wird benutzerfreundlich darauf hingewiesen, dass der Benutzer ein falsches Passwort oder einen falschen Benutzernamen verwendet hat. Diese Fehlermeldungen haben den Nachteil, dass ein Angreifer Rückschlüsse ziehen kann. Der Angreifer weiß, wenn die Fehlermeldung ein falsches Passwort anzeigt, dass der Benutzername auf jeden Fall in der Datenbank der Web-Anwendung existiert. Sobald diese Fehlermeldung in einer Web-Anwendung nicht integriert ist, kann ein Angreifer nicht mehr herausfinden, ob der Benutzername existiert. Nun können direkte Timing-Angriffe abhelfen. Die Web-Anwendung prüft die Eingabewerte nach einer festgelegten Reihenfolge. Das System muss zum Beispiel bei der Anmeldung eines Benutzers eine Liste aller existierenden Benutzernamen in der Datenbank nach dem eingegebenen Benutzernamen durchsuchen, siehe Abb Sollte kein Treffer in der Datenbank vorhanden sein, muss das System alle Benutzernamen der Liste durchlaufen. Die Antwortzeit des Webservers verlängert sich dementsprechend. Der Angreifer muss lediglich die Zeit vor und nach der Anfrage messen. Der Zeitunterschied zwischen einer Webserver Antwort bei existierendem Benutzer und nicht existierendem Benutzer kann ausgewertet werden, um an gewünschte Informationen zu gelangen wie zum Beispiel ob ein Benutzername auf der Web-Anwendung existiert Cross-Site Timing-Angriffe Im Gegensatz zu einem direkten Timing-Angriff wird bei einem Cross-Site Timing-Angriff (Bortz und Boneh 2007) über eine andere Webseite versucht, an für den Angreifer unsichtbare Informationen zu gelangen. Dabei wird der Angriff über eine andere Webseite

14 2.1. Timing-Seitenkanäle 7 gefahren, der durch einen Benutzer dieser anderen Webseite gestartet wird. Dabei wird der Benutzer nichts von den Anfragen an den Webserver der anzugreifenden Web-Anwendung mitbekommen, obwohl der Angreifer nun Zeitmessungen von dem Benutzer übermittelt bekommt. Ein Vorteil über den Cross-Site Timing-Angriff bietet die Möglichkeit, die Sitzungs-ID des Benutzers zu nutzen. Diese Sitzungs-ID wird zu Beginn einer Sitzung von der anzugreifenden Web-Anwendung generiert. Der Benutzer Webbrowser speichert diese Sitzungs-ID und weist sich bei der Web-Anwendung damit aus. Sobald der Benutzer nun auf eine mit Cross-Site Timing Angriff versehene Webseite gelangt, kann der Angreifer über die Antwortzeit der anzugreifenden Web-Anwendung Informationen über den Benutzer erlangen. Über die Sitzungs-ID kann der Webserver seinen Benutzer identifizieren und abhängig von dem jeweiligen Inhalt den Benutzerbereich laden. Die Bearbeitungszeit des Webservers ist somit abhängig von der Gültigkeit oder der Inhalte des Benutzer-Kontos. Diese Antwortzeiten kann der Angreifer für sich nutzen. Ablauf von Cross-Site Timing-Angriffen Zum genaueren Verständnis wird hier ein kurzer abstrakter Ablauf des Cross-Site Timing- Angriffes vorgestellt. Eine Möglichkeit diese Angriffe durchzuführen, bietet der sogenannte <IMG> Tag. Der <IMG> Tag ist ein Befehl, der in HTML benutzt wird, um die Einzelheiten einer Grafikreferenz zu bestimmen. Mit dem Attribut src wird die gewünschte Grafikdatei referenziert (SELFHTML 2007). Sollte es sich nicht um eine Grafikdatei handeln, wird ein Fehler geworfen. Ein Cross-Site Timing-Angriff kann dies nun mit Hilfe von JavaScript zum Messen von Antwortzeiten einer Web-Anwendung nutzen. JavaScript bietet sich für diesen Zweck besonders gut an, da für HTML Elemente verschiedene Event- Handler definiert werden können. In diesem Fall kann der onerror Event-Handler dazu benutzt werden, um JavaScript Code auszuführen, wenn ein Fehler geworfen wird. Dadurch wird es möglich, die Zeit des Ladens von allen beinhaltenden Bildern, Java Applets, Skripten und Stylesheets zu messen. Die Event-Handler können als Timing-Seitenkanal genutzt werden. Folgende Schritte werden bei einem Cross-Site Timing-Angriff durchgeführt, auch veranschaulicht in Abb. 2.2: 1. Ein Benutzer gelangt auf eine Timing-Angriff Webseite. Im Hintergrund der Webseite kann nun der Cross-Site Timing-Angriff gestartet werden. 2. Der Angreifer kann über unsichtbare Bildelemente dem Attribut src die URL, der anzugreifenden Web-Anwendung, übergeben. 3. Der Webbrowser des Benutzers lädt das Bildelement und führt so eine Anfrage an den anzugreifenden Webserver aus. Vor der Übergabe des URL an das src Attribut wird die Zeit im JavaScript gestoppt.

15 2.2. Web Application Firewall 8 4. Der Webserver der anzugreifenden Web-Anwendung bearbeitet die Anfrage und gibt eine Antwort zurück. Für diese Antwort braucht der Webserver unterschiedlich lange Zeit, wenn der Benutzer angemeldet oder nicht angemeldet ist. 5. Der Webbrowser bemerkt, dass es sich nicht um ein Bild handelt und führt eine onerror Fehlerbehandlung aus. In dieser Fehlermeldung wird die Zeit nochmals gestoppt. Die Antwortzeit kann nun ermittelt werden, indem die Startzeit von der Endzeit subtrahiert wird. Abb. 2.2.: Ablauf Cross-Site Timing-Angriff. Der Ablauf eines Cross-Site Timing-Angriffes kann genauso gut zur Verschleierung der IP- Adresse des Angreifers in den Log-Dateien einer WAF verwendet werden. Der Benutzer steht somit in den Log-Dateien und der Angreifer kann seine Daten beruhigt auswerten ohne von dem anzugreifenden Webserver erkannt worden zu sein Web Application Firewall Die WAF (Spenneberg 2009), auch bekannt als WebShields (Bundesamt 2006), schützt die Web-Anwendung beispielsweise vor Angriffen wie SQL-Injection, XSS und Directory Traversal. Die WAF überprüft den Datenstrom vom Webbrowser zur Web-Anwendung auf Angriffe. Sobald eine unzulässige Eingabe getätigt wird, filtert die WAF den Datenstrom. Um solche unzulässigen Eingabemuster zu erkennen, besitzt die WAF eine Reihe von Filterregeln, die durch den Webseiten-Entwickler manuell konfiguriert werden können. Dabei können Filterregeln unterschiedlich für einzelne Parameter auf der Web-Anwendung definiert werden. Deshalb sind die Filterregeln einer WAF für den Benutzer der Web- Anwendung nicht bekannt. Die WAF lässt sich in verschiedene Netzumgebungen (Marx 2009) einsetzen. Dabei unterscheidet man zwischen der Integration als Reverse Proxy und Bridge. Letzteres benennt die Möglichkeit, eine WAF wie ein Switch zwischen Browser und Web-Server einzubauen. Ein Switch teilt die Datenströme auf. So ist es möglich, dass die WAF den Netzwerkverkehr passiv mitlesen kann. Ersteres ist die häufiger eingesetzte Variante. Die WAF sitzt zwischen dem Browser des Benutzers und dem Webserver. Die Eingaben des Benutzers

16 2.2. Web Application Firewall 9 Abb. 2.3.: Ablauf Web Application Firewall. kommen somit zuerst bei der WAF an und werden dort auf Zulässigkeit geprüft. Danach schickt die WAF die Eingaben weiter an die Web-Anwendung. Sollte eine unerlaubte Eingabe getätigt werden, wird die Anfrage direkt in der WAF blockiert, siehe Abb Die WAF kann je nach Einstellung nun eine Fehlermeldung zurückgeben. Sollten sich Fehlermeldungen von WAF und Web-Anwendung bis auf das Detail gleichen, wird die Sicherheit einer Web-Anwendung erhöht, da ein Angreifer keinen Rückschluss darauf ziehen kann, wie weit der Angriff gelangt ist. Die Übermittlung der Parameter kann über sogenannte GET- und POST-Methode an den Webserver erfolgen. Bei der GET-Methode werden die Parameter in der URL übermittelt. Bei der POST-Methode erfolgt die Übermittlung über Formularfelder, die durch den Benutzer gefüllt werden. Aber es können auch für den Benutzer unsichtbare Parameter, sogenannte Hidden-Parameter, übermittelt werden. Bei beiden Methoden ist es möglich, den Wert der Parameter zu manipulieren. Die WAF überprüft alle Parameter auf ihre Filterregeln. Auch Hidden-Parameter sollten von der WAF geprüft werden, da diese genauso von einem Angreifer manipuliert werden könnten, wie alle anderen Parameter ModSecurity In dieser Bachelorarbeit wird beispielhaft die WAF ModSecurity (ModSecurity 2011) (Ristic 2010) verwendet. ModSecurity ist ein WAF Plug-In für den Apache Webserver und ist bekannt für seine extrem flexible und robuste Filterregelung. ModSecurity bietet als Open-Source Produkt einige Vorteile. Ein Vorteil ist, dass der Apache Webserver viele Betriebssysteme unterstützt, wie zum Beispiel Linux oder Windows Betriebssysteme. Allerdings kann ModSecurity nicht ohne den Apache Webserver genutzt werden, da dieser das Parsing der URL der Anfrage übernimmt (Spenneberg 2009). Dadurch das ModSecurity nur die Resultate filtern muss, besitzt es eine deutlich weniger hohe Last als andere WAFs (Spenneberg 2009). Im Folgenden werden zwei in dieser Bachelorarbeit verwendeten Installationsoptionen von ModSecurity vorgestellt.

17 2.2. Web Application Firewall 10 Installation in der demilitarisierten Zone Bei der Installation in der demilitarisierten Zone wird ModSecurity auf einem eigenen Apache Webserver installiert (Spenneberg 2009), der als Reverse-Proxy konfiguriert ist. Von dort aus schützt die WAF die eigentliche Web-Anwendung. ModSecurity sitzt somit zwischen dem Benutzer und dem Webserver in der demilitarisierten Zone. Diese Installationsoption ist für das Fingerprinting durch Timing-Seitenkanäle am besten geeignet, weil hier die besten Messergebnisse zu erwarten sind. Auf der Abb. 2.4 wird veranschaulicht, welchen Weg eine Anfrage vom Benutzer zurücklegt. Dabei stellen die gestrichelten Linien eine von der WAF blockierte Anfrage dar und die durchgezogenen Linien eine von der WAF nicht blockierte Anfrage. Bei dem ersten Fall wird die Anfrage von der WAF blockiert und eine Fehlermeldung dort generiert. Im zweiten Fall wird eine Anfrage an die Web-Anwendung durch gereicht, wo die Anfrage verarbeitet wird. Der Weg den die Anfrage zurücklegt ist dabei unterschiedlich lang. Dieser Weg schlägt sich auch auf die Antwortzeit des Webservers aus. Ein kürzerer Weg entspricht einer schnelleren Antwortzeit des Webservers und ein längerer Weg entspricht einer längeren Antwortzeit des Webservers. Somit ist bei dieser Installation der WAF der längste Zeitunterschied zwischen blockierten und nicht blockierten Anfragen zu erwarten. Abb. 2.4.: ModSecurity: Installation Reverse-Proxy. Installation auf dem Webserver Bei der Installation auf dem Webserver wird ModSecurity als Plug-In (Spenneberg 2009) im Apache auf dem gleichen Webserver wie die Web-Anwendung integriert. Der zeitliche Weg von ModSecurity zur Web-Anwendung verkürzt sich hierbei stark, siehe Abb In diesem Fall werden weniger gute Messergebnisse durch Timing-Seitenkanäle zu erwarten sein, da der zeitliche Unterschied weniger groß ausfallen sollte. Der Zeitunterschied zwischen blockierten und nicht blockierten Anfragen sollte sich verkürzen, da ModSecurity und die Web-Anwendung auf dem gleichen Webserver liegen. Ein größerer Zeitunterschied ist einfacher messbar, da das Rauschen leichter auszufiltern ist.

18 2.3. Verwundbarkeiten von Web-Anwendungen 11 Abb. 2.5.: ModSecurity: Installation auf dem Webserver PHPIDS PHPIDS (PHPIDS 2011) ist ein auf PHP basierende WAF. Das einfache Einbinden der PHPIDS Bibliothek in die eigene Web-Anwendung soll diese vor Angriffen wie SQL- Injection oder XSS schützen. Dabei enthält PHPIDS bereits Filterregeln und ist besonders einfach zu nutzen. Im Bereich der Timing-Seitenkanäle wird diese Art des Schutzes vor Angriffen auf eine Web-Anwendung, die schlechtesten Messergebnisse bereitstellen. Wie auf der Abb. 2.6 gezeigt, ist der zeitliche Unterschied zwischen einer von der PHPIDS blockierten Anfrage und der nicht blockierten Anfrage sehr gering. Abb. 2.6.: Bibliothek PHPIDS eingebunden Verwundbarkeiten von Web-Anwendungen Web-Anwendungen können anfällig für die verschiedensten Arten von Angriffen sein. Durch Eingabefelder oder Manipulationen der URL können Benutzer Angriffe auf die Web-Anwendung starten. Der Benutzer kann einzelne Werte für Parameter verändern und somit der Web-Anwendung unerwartete Werte übermitteln. Sollte die WAF die Parameter einzeln auf Richtigkeit prüfen, kann es passieren, dass zum Beispiel in einem Name Feld das Hochkomma erlaubt ist und für andere Felder nicht. Dieses Hochkomma kann dann für diesen Parameter für Angriffe verwendet werden. Durch ausprobieren kann ein Angreifer nun Angriffe starten, die eventuell nicht blockiert werden. Dabei gibt es viele Angriffsarten, die mit Hilfe von Timing-Seitenkanälen ebenso ausgenutzt werden

19 2.3. Verwundbarkeiten von Web-Anwendungen 12 können. Diese Bachelorarbeit agiert am Beispiel der drei Angriffe SQL-Injection, XSS und Directory Traversal, die im Folgenden kurz beschrieben werden SQL-Injection Der SQL-Injection Angriff (Auger und Barnett 2010) (Holm und Schwardt 2007) greift die Datenbank im Hintergrund einer Web-Anwendung an. Über SQL-Befehle werden Änderungen an dieser Datenbank vorgenommen oder Daten ausgelesen. Web-Anwendungen bieten die Möglichkeit, die eigenen Benutzerdaten zu ändern. Diese Änderung wird in der Datenbank mit Hilfe von einem SQL-Befehl durchgeführt. Wenn die Web-Anwendung schlecht geschützt ist, kann ein Angreifer diese Zeichenkette verändern und eigene SQL- Befehle einfügen. Der Angreifer erlangt so die Möglichkeit, die Datenbank mitzugestalten. Um solche Angriffe zu verhindern, muss die Web-Anwendung die Eingaben validieren oder eine WAF installieren. In dem SQL-Befehl 2.1 wird in der Datenbank Benutzer die Spalte Benutzername angesprochen. Mit Hilfe der WHERE Bedingung wird nun festgelegt, welcher Benutzer gesucht wird. Hier wird der Benutzer mit dem Namen Peter und dem Passwort pw selektiert: 1 SELECT Benutzername 2 FROM Benutzer 3 WHERE Benutzername = Peter 4 AND Password = pw ; Quellcode 2.1: Normaler SQL-Befehl Dieser SQL-Befehl kann von einem Angreifer abgeändert werden. Dabei bietet sich an, sollte man das Passwort nicht kennen, einen passenden SQL-Injection Angriff zu nehmen, der den SQL-Befehl wie folgt aussehen lässt: 1 SELECT Benutzername 2 FROM Benutzer 3 WHERE Benutzername = Peter 4 AND Passwort = OR 1=1; ; Quellcode 2.2: SQL-Befehl mit SQL-Injection Dieser SQL-Befehl macht die Passwort Abfrage nebensächlich, denn das Codefragment 1=1 gibt immer den Wert wahr zurück. Somit wird die Bedingung Passwort = OR 1=1 immer wahr. Die beiden Endzeichen ; werden mit Hilfe von -- auskommentiert, um einen syntaktisch richtigen SQL-Befehl zu erhalten. Der Angreifer kann somit den Benutzer festlegen, obwohl er das Passwort nicht kennt. Die Inhalte für die Felder Benutzername und Password werden dem System meist über Eingabefelder übermittelt. So muss der Angreifer lediglich folgendes eingeben:

20 2.3. Verwundbarkeiten von Web-Anwendungen 13 Benutzername: Peter Passwort: OR 1=1 ;-- Und schon kann der Angreifer, sollte eine SQL-Injection Sicherheitslücke vorhanden sein, sich als Benutzer Peter anmelden, da die WHERE Bedingung immer wahr ist Cross-Site Scripting XSS (Spenneberg 2009) (Lichtner 2009) (Auger 2011) (Microsoft XSS 2011) ermöglicht es dem Angreifer an vertrauliche Daten zu kommen oder Inhalte zu ändern. Anfällig für diese Angriffsart sind vor allem Web-Anwendungen, die keine Eingabe Validierung besitzen und Benutzereingaben wieder auf der Webseite anzeigen. So kann es möglich werden, im Kontext einer anfälligen Web-Anwendung, böswilligen JavaScript Code auszuführen. Der Webbrowser erkennt diese nicht und führt die JavaScripts aus. Damit wird es für den Angreifer zum Beispiel möglich, an die Sitzungs-ID des momentanen Benutzers zu kommen oder die komplette Seitenstruktur zu verändern. Mit Hilfe des laufenden JavaScripts kann der Angreifer die Web-Anwendung so manipulieren, dass sie die Daten an den Angreifer schickt. Das JavaScript wird nicht durch die Same-Origin-Policy (Same- Origin-Policy 2010) blockiert, da Protokoll, Domain und Port mit der Web-Anwendung übereinstimmen. Im folgenden Beispiel wird eine anfällige Web-Anwendung so manipuliert, dass die Sitzungs-ID an einen böswilligen Angreifer gesendet wird: Über Spam s kann ein Angreifer die Benutzer auf diesen Link locken. Meist werden dem Benutzer verlockende Angebote gemacht, damit er den Link besucht. Einem solchen Link sieht man seine Bösartigkeit meist nicht an. Folgende URL ist die verschleierte Variante des obigen URL-Beispiels: name=%3cscript%3esendecookie()%3b%3c%2fscript%3e Der Webbrowser kann diesen Code ausführen. Der Benutzer bekommt auf der Web- Anwendung von dem im Hintergrund laufenden JavaScript nichts mit und wird sich weiterhin sicher fühlen. Durch die Encodierung des JavaScripts mit der URL-Kodierung, kann der Angreifer den Benutzer noch besser täuschen. Ein einfaches Beispiel für XSS ist das Ändern einer Überschrift (Microsoft XSS 2011). Es können über den URL Pfad auch Werte für Parameter übergeben werden, die bei Aufruf der Web-Anwendung zu einer Textausgabe führen. Ein einfaches Beispiel dafür ist, die Änderung einer Überschrift auf der Web-Anwendung, die durch folgende URL stattfindet.

21 2.3. Verwundbarkeiten von Web-Anwendungen 14 Der Parameter title erhält den Wert Hallo Welt, welcher im Quellcode als Überschrift <h1>hallo Welt</h1>eingefügt wird. Bei einem XSS Angriff wird nun, der Parameter abgeändert: <script>alert( XSS%20attack )</script> Nun wird direkt nach der Überschrift ein JavaScript ausgeführt, welches einen böswilligen Angriff beinhalten kann. Der Inhalt im Quellcode der Web-Anwendung sieht dann wie folgt aus: <h1>hallo Welt</h1><script>alert( XSS attack )</script> Auf der Webseite wird nun die Meldung XSS attack erscheinen. Anstelle dieser Meldung kann nun schädlicher Code eingefügt werden Directory Traversal Bei einem Directory Traversal Angriff (Holm und Schwardt 2007) versucht ein Angreifer auf Dateien zuzugreifen, die für ihn eigentlich nicht einsichtig sein sollten. Auf dem Webserver (Rubin und Geer 1998) liegen zwei Verzeichnisse, das Serververzeichnis und das Dokumentenverzeichnis. Ersteres beinhaltet die Server Kontroll-Informationen. Im Dokumentenverzeichnis wird der Inhalt der Webseite gespeichert. Oftmals liegt das Dokumentenverzeichnis im Serververzeichnis. Das Serververzeichnis sollte generell vom Webserver geschützt werden und nicht im Internet bereitgestellt werden, da dort Konfigurationsdateien gespeichert werden. Ein häufiger Fehler kann eine falsche Konfiguration der Zugriffsrechte sein. Ein Zugriff auf eine im Dokumentenverzeichnis liegenden Datei erfolgt zum Beispiel über den Pfad /var/www/index.php. In der späteren URL, dem Zugriffspfad einer Web-Anwendung, sollte dabei nur der Pfad /index.php erscheinen. Ein Angreifer kann versuchen durch die Manipulation dieser Pfadangabe das Verzeichnis zu wechseln und Dateien auszulesen. Dafür hängt der Angreifer an die URL Strings wie zum Beispiel../ oder../../ an. Sollten solche Strings nicht von einer WAF oder der Web-Anwendung selbst blockiert werden, kann der Angreifer in den Verzeichnissen des Webservers nach vertraulichen Informationen wie Passwörtern suchen. Ein Beispiel dafür ist diese Manipulation der URL zu: Durch den Anhang von /../../ kann in dem Verzeichnis des Skripts index.php auf zwei Ebenen unter dem momentanen Ordner zugegriffen werden. Ein Angreifer kann dann auf dort liegende Dateien zugreifen, wenn eine Schwachstelle vorhanden sein sollte. Im Beispiel könnte der Angreifer auf die Datei passwd, in der Linux Passwörter Hashes speichert.

22 3. Fingerprinting von WAF-Filterregeln durch Timing-Seitenkanäle In diesem Kapitel wird der Ablauf des Fingerprinting der WAF-Filterregeln beschrieben sowie erläutert, wie hierfür Timing-Seitenkanäle ausgenutzt werden. Zum Schutz vor Angriffen werden Web-Anwendungen durch WAFs gesichert. Alle Anfragen auf eine Web- Anwendung werden dabei durch die WAF geleitet. Mit Hilfe von Filterregeln entscheidet die WAF, welche Zeichen und Zeichenketten in den Anfragen erlaubt sind, um sofort nicht legitime Anfragen auszufiltern. Deutet die WAF eine Anfrage als unzulässig, so blockiert sie die Anfrage und gibt eine Fehlermeldung an den Anfragenden zurück. Die Fehlermeldung der WAF und der Web-Anwendung sollten dabei immer gleich ausfallen, damit ein Angreifer keine Rückschlüsse über die aktiven Filterregeln erlangen kann. Somit ist nicht zu erkennen, ob die Fehlermeldung von der WAF oder von der Web-Anwendung geschickt wird. Abb. 3.1.: Timing-Seitenkanäle bei Verwendung einer WAF. Trotzdem gibt es die Möglichkeit durch Timing-Seitenkanäle zu ermitteln, welche Fehlermeldung von der WAF kommt und welche von der Web-Anwendung. Eine direkt von der WAF blockierte Anfrage wird nicht weiter an die Web-Anwendung gegeben und die WAF erzeugt sofort eine Fehlermeldung. Nach Abb. 3.1 (gestrichelte Linien), besitzt eine von der WAF blockierten Anfrage einen viel kürzeren Bearbeitungsweg. Die WAF gibt dabei in messbar kürzerer Zeit eine Fehlermeldung zurück. Im Gegensatz dazu, braucht eine von der WAF nicht blockierte Anfrage viel mehr Bearbeitungszeit. Die Anfrage kommt bis zur Web-Anwendung vor und wird dort bearbeitet, siehe durchgezogene Linien. Dabei kann 15

23 3.1. Fingerprinting mit direkten Timing-Angriffen 16 es bei einer unzulässigen Anfrage zu Fehlern kommen, dann schickt die Web-Anwendung eine Fehlermeldung zurück. Der Benutzer der Web-Anwendung kann dabei nicht direkt darauf schließen, ob die Fehlermeldung von der Web-Anwendung kommt oder von der WAF. Trotzdem ist es möglich, eine Aussage über die Herkunft der Fehlermeldung zu treffen. Die Antwortzeit des Webservers ist bei einer durch die WAF blockierten Anfrage wesentlich kürzer als bei einer durch die Web-Anwendung geworfenen Fehlermeldung. Dieser Zeitunterschied ist mess- und auswertbar. Es sollte somit für einen Angreifer möglich sein, die WAF auf Filterregeln von Zeichen, die für Angriffe nötig sind, zu testen. Für einen intelligenten Angriff sind Informationen über die Filterregeln unerlässlich. Beim Schreiben eines Angriffes, kann der Angreifer Informationen darüber, ob sein Angriff bereits durch die WAF gekommen ist, gut gebrauchen. Sollte der Angriff bereits durch die WAF kommen, hat der Angreifer vielleicht lediglich einen Datenbanknamen falsch geschrieben oder einen ähnlichen Fehler gemacht. In den folgenden Unterkapiteln wird der genaue Ablauf des Fingerprinting durch Timing- Seitenkanäle in einzelne Schritte untergliedert. Dafür wird der direkte Timing-Angriff verwendet. Dieser Ablauf gilt ebenso für den im zweiten Unterkapitel vorgestellten Cross-Site Timing-Angriff basierenden Fingerprint. Der während dieser Bachelorarbeit entwickelte Prototyp befolgt genau diesen Ablauf Fingerprinting mit direkten Timing-Angriffen Der direkte Timing-Angriff (Kapitel 2.1.1) besteht aus einer direkt an den Webserver gesendeten Anfrage. Für das Fingerprinting werden mehrere solcher Anfragen an den Webserver geschickt. Die Antwortzeit des Webservers wird ermittelt, indem vor und nach der Anfrage die Zeit gestoppt wird. Danach wird die Startzeit von der Endzeit subtrahiert, um so ein Messergebnis zu erreichen. Bevor solche Anfragen versendet werden können, werden die Zeichen und Zeichenketten, die in der Anfrage als Wert der Parameter verwendet werden, benötigt. Diese Zeichen und Zeichenketten sollten als erstes definiert werden, wie in Kapitel beschrieben. In Kapitel wird der erste Schritt erläutert. Die WAF sollte natürlich für ein Fingerprinting vorhanden sein und ein Test muss zeigen, mit welchem Grenzwert, die Messungen nach den Kategorien blockiert und nicht blockiert untergliedert werden. Für den nächsten Schritt wird, wie in Kapitel erklärt, die Webseite auf Parameter durchsucht, um möglichst alle Parameter im Fingerprinting zu nutzen. Im nächsten Kapitel findet nun das eigentliche Fingerprinting statt. Die Messungen werden gestartet und die Messergebnisse in blockierte und nicht blockierte Anfragen unterteilt. Der letzte Schritt in Kapitel wertet die Messergebnisse aus.

24 3.1. Fingerprinting mit direkten Timing-Angriffen Definition von Zeichen und Zeichenketten Ein Angriff auf eine Web-Anwendung benötigt bestimmte Zeichenketten. Diese Zeichenketten bestehen aus einer bestimmten Reihenfolge von Zeichen. Die Filterregeln der WAFs können Zeichen in einem bestimmten Rahmen zulassen und Zeichenketten, mit einer Reihe von einzeln nicht blockierten Zeichen, blockieren. Zum Beispiel kann in einem Nachname Eingabefeld das Hochkomma erlaubt sein, damit Namen wie O Neill problemlos eingegeben werden können. Jedoch ist das Hochkomma ein wesentlicher Bestandteil einiger Angriffe auf Web-Anwendungen. Deshalb wird das Hochkomma oft erst in einer bestimmten Zeichenkette durch die WAF blockiert. Im Rückschluss werden von der WAF blockierte Zeichen, auch in einer Zeichenkette blockiert. Diese Zeichen und Zeichenketten können nach Angriffsarten sortiert werden, damit ein Überblick gewährleistet bleibt. Abb. 3.2.: Unendliche Angriffsvariationen. Das Ermitteln solcher Zeichen und Zeichenketten ist keinesfalls leicht, denn es gibt unendlich viele Angriffe, die erst einmal gefunden werden müssen. In Abb. 3.2 werden zwei Angriffe gezeigt, bei denen es unendlich vielen Möglichkeiten gibt. Bei der Wahrheitsgleichung können jegliche Zahlen oder Buchstaben-Kombinationen verwendet werden, es muss nur immer eine wahre Gleichung herauskommen. Ebenso ist es möglich, die Angriffe zu verschleiern, indem einfache Leerzeichen in die Angriffe eingefügt werden. Dabei können unendlich viele Leerzeichen eingefügt werden ohne das der Angriff an Stärke verliert. Somit ist das Erstellen einer solchen Black List wesentlich schwieriger als das Erstellen einer White List (SecureNet GmbH 2006) Erkennen einer verwendeten WAF Der erste auszuführende Schritt sollte ein Test sein, der feststellt, ob eine WAF existiert. Der Zeitunterschied der Antwortzeit des Webservers zwischen einer blockierten und nicht blockierten Anfrage sollte messbar sein. Hierfür kann ein fester Wert festgelegt werden. Außerdem sollte eine Abfrage prüfen, ob der Zeitunterschied überhaupt vorhanden ist. Die Zeitmessungen von nicht blockierten Anfragen sollten größtenteils oberhalb von den Zeitmessungen von blockierten Anfragen liegen. Sollten die Zeitmessungen kaum Zeitunterschiede aufweisen, so ist es nicht möglich, das Fingerprinting durch Timing-Seitenkanäle durchzuführen. Ein möglicher Grund dafür, kann eine fehlende oder nicht blockierende WAF darstellen.

25 3.1. Fingerprinting mit direkten Timing-Angriffen 18 Im Folgenden wird beschrieben, wie die Messungen für den ersten Test sinnvoll durchgeführt werden können. Außerdem muss für den weiteren Testverlauf ein Grenzwert ermittelt werden, der entscheidet, welche Anfragen als blockiert oder nicht blockiert deklariert werden. Messungen durchführen Zur Erstellung eines Grenzwertes sollte ein erster Test durchgeführt werden. Als erstes sollte eine von der WAF nicht blockierte Anfrage mehrmals an den Webserver geschickt und die Antwortzeit gemessen werden. Um das Rauschen besser ausfiltern zu können, sollte eine hohe Anzahl an Anfragen genommen werden, zum Beispiel 100 Anfragen. Damit diese Anfrage ganz sicher nicht blockiert wird, sollte die Anfrage manuell auf der Web- Anwendung getestet werden. Der erste Test benötigt dann URL, Parameter und Wert des Parameters für die Anfragen. Für die von der WAF blockierte Anfrage wird eine besonders bekannte Anfrage verwendet. Zum Beispiel der SQL-Injection Angriff OR 1=1 --. Diese Anfrage wird genau wie die nicht blockierte Anfrage mehrmals an die Web-Anwendung gesendet. Mit Hilfe dieser 200 Zeitmessungen kann nun der Grenzwert für das Fingerprinting errechnet werden. Die 200 Anfragen des ersten Tests sind auf der Abb. 3.3 dargstellt. Abb. 3.3.: Erster Test: Relation Grenzwert.

26 3.1. Fingerprinting mit direkten Timing-Angriffen 19 Errechnung des Grenzwertes Der Grenzwert wird aus den 200 Anfragen des ersten Tests erstellt. Als erstes wird eine obere Grenze für den Grenzwert ermittelt. Das Rauschen in den Messergebnissen ist additiv (Bortz und Boneh 2007), somit kann eine obere Grenze für den Grenzwert anhand des Minimums der Zeitmessungen von nicht blockierten Anfragen ermittelt werden. Um den Zeitunterschied erfassen zu können, muss nun eine untere Grenze ermittelt werden. Die untere Grenze ist schwieriger zu ermitteln, da das Rauschen additiv ist und somit ein Maximum höher als das Minimum der validen Anfragen werden kann. Die höheren Messergebnisse werden von mehr Rauschen beeinflusst. Somit müssen Messergebnisse mit zu hohem Rauschen aussortiert werden. In dieser Bachelorarbeit wird dies gelöst, in dem das 0,9-Quantil (Georgii 2004) der invaliden Anfragen gewählt wird. Dafür werden die Zeitmessungen der Größe nach, von klein nach groß, sortiert. Als untere Grenze wird der Messwert gewählt, bei dem 90% aller Messergebnisse kleiner als dieser Messwert sind. Dies ist beim 90. Messwert in der sortierten Liste der Fall. Daher wird der 90. Messwert der sortierten invaliden Anfragen als untere Grenze gewählt. Das gleiche Ergebnis kann errechnet werden, indem man von den sortierten Messergebnissen, die Größten 10% streicht und von den überbleibenden Messwerten den größten Messwert wählt. Abb. 3.4.: Errechnung des Grenzwertes. Nach der Ermittlung einer oberen und unteren Grenze wird der Puffer errechnet. Dafür wird die untere Grenze von der oberen Grenze subtrahiert und von dem Ergebnis die Hälfte genommen. Dieser Puffer wird nun von der oberen Grenze abgezogen. Nun erhält man einen Grenzwert der zwischen den blockierten und nicht blockierten Anfragen liegt. Die Berechnung des Grenzwertes wird in Abb. 3.4 nochmals veranschaulicht. Natürlich ist der Grenzwert ein Schätzwert und kann bei höherem Rauschen zu einem ungenauen Fingerprinting der Filterregeln führen. Aber wie im Praxis Test in Kapitel 4 gezeigt, liegen gerade mal unter 10 Werte der invaliden Anfragen weit über den restlichen Messergebnissen, siehe dazu nochmals Abb Ermitteln der Parameter Im zweiten Schritt werden die Parameter der Web-Anwendung benötigt. Eine Web-Anwendung kann eine Vielzahl an Parametern haben und jeder Parameter kann eigene Filterregeln be-

27 3.1. Fingerprinting mit direkten Timing-Angriffen 20 sitzen. Somit muss für ein Fingerprinting der WAF-Filterregeln jeder Parameter auf alle zu prüfenden Zeichen und Zeichenketten geprüft werden. Die Filterregeln eines Eingabefeldes für einen Nachnamen können anders als die Filterregeln eines Postleitzahlen-Eingabefeldes definiert sein. Im späteren Testverlauf werden somit die Parameter der Web-Anwendung benötigt. Da jeder Parameter in einem bestimmten Kontext verwendet wird, sollte der passende Pfad ebenfalls mit ermittelt werden. Damit das spätere Fingerprinting die Parameter mit passender URL nutzen und mit den einzelnen Angriffen kombinieren kann Durchführung des Fingerprinting In diesem Schritt werden die eigentlichen Zeitmessungen durchgeführt. Die im ersten Schritt definierten Zeichen und Zeichenketten, die für die einzelnen Angriffe von Nöten sind, werden auf jeden Parameter der Web-Anwendung getestet. Die Antwortzeiten des Webservers geben Aufschluss darüber, ob eine Zeichenkette durch die Filterregeln der WAF gekommen ist oder nicht. Die Zeit wird vor und nach der Anfrage an den Webserver gestoppt. Dann wird die Startzeit von der Endzeit subtrahiert, um die eigentliche Antwortzeit zu ermitteln. 1 / 2 This methode measures the r e q u e s t response times. 3 / 4 f u n c t i o n measurerequest ( $para, $request, $basepath ) { 5 6 // s t a r t measurement 7 $ t i m e s t a r t = Rdtsc : : g e t t i c k s ( ) ; 8 9 // r e q u e s t the page 10 $webapplication f i l e g e t c o n t e n t s ( $basepath. "?". "$para". "=". $ r e q u e s t ) ; // end measurement 13 $time end = Rdtsc : : g e t t i c k s ( ) ; // c a l c u l a t e the time d i f f e r e n c e 16 $time = $time end $ t i m e s t a r t ; return $time ; 19 } Quellcode 3.1: Messung der Webserver Antwortzeit Zum Messen der Antwortzeiten des Webservers bieten sich besonders Zeitmessungen im Nanosekunden Bereich an. Umso kleiner die Zeiteinheit gewählt wird, umso eher wird ein

28 3.1. Fingerprinting mit direkten Timing-Angriffen 21 Zeitunterschied messbar. In dieser Bachelorarbeit werden CPU-Takte zur Zeitmessung verwendet. Ein Intel Prozessor besitzt einen Zeitstempel Zähler (Corporation 1998). Dieser Zähler kann für die Messungen von Timing-Seitenkanälen genutzt werden. Die Takte der CPU werden in diesem Zeitstempel gezählt. Der Zeitstempel lässt sich durch den Befehl Read Time-Stamp Counter (RDTSC) in einem PHP Skript auslesen. In dem Quellcode 3.1 wird die Messmethode gezeigt. Die Zeitmessung erfolgt über den externen PHP Befehl Rdtsc::getticks() (crrodriguez 2011). Diese Methode liest die CPU- Takte aus. Dabei werden vor und nach der Anfrage an den Webserver die CPU-Takte gemessen. Die Anfrage benötigt den URL-Pfad des Webservers, einen Parameter dieses Pfades und eine Anfrage. Die Anfrage besteht aus einer der in Kapitel beschriebenen Zeichen und Zeichenketten. Der Parameter und alle Zeichenketten, die bis zur Web-Anwendung gelangt sind, sollen dabei am Ende gespeichert werden. Ob ein Zeichen oder eine Zeichenkette von der WAF blockiert oder nicht blockiert wurde, wird anhand des Grenzwertes ermittelt. Alle Codefragmente sollten beispielsweise 5 mal geprüft werden. Liegen dann mindestens 3 Zeitmessungen der Antwortzeiten unter dem Grenzwert, so wird diese Anfrage als von der WAF blockiert deklariert. Jeder Angriff wird auf jeden Parameter einer URL durchgeführt. Dabei wird darauf geachtet, dass jeweils nur ein Parameter versendet wird. Zur Auswertung der Messergebnisse ist es wichtig, dass immer nur ein Parameter an die Web-Anwendung versendet wurde, damit ein Rückschluss auf die Filterregeln möglich ist. Bei mehreren Parametern wäre dies nicht möglich, da der Benutzer nicht weiß, ob die Filterregeln bei dem ersten Parameter oder bei einem anderen Parameter gegriffen haben Auswertung der Messergebnisse Im letzten Schritt können die Messergebnisse graphisch dargestellt werden. Um genau zu erkennen, welche Angriffe auf eine URL möglich sind, werden nur nicht blockierte Anfragen aufgelistet. Dabei können die Anfragen nach ihrer Angriffsart geordnet werden, siehe Abb Eine Zuordnung nach Zeichen und Zeichenketten verschafft einen guten Überblick. Danach können alle URLs, mit den dazugehörigen Parametern, angezeigt werden. Für die einzelnen Parameter können dann alle nicht blockierten Anfragen angezeigt werden. Der Prototyp in dieser Bachelorarbeit verwendet eine Baum Menü Bibliothek für PHP(HTML TreeMenu 2010). In dem Baum Menü können alle möglichen Anfragen aufgelistet werden. Bei dem Erstellen des Baum Menü, sollte darauf geachtet werden, dass keine unnötigen Duplikate aufgelistet werden. Außerdem beinhalten, die Zeichen und Zeichenketten, oftmals Sonderzeichen, die in einer anderen Programmiersprache zu Fehlern führen können. Des Weiteren ist es möglich eine.txt oder.csv Datei nach den

29 3.2. Fingerprinting mit Cross-Site Timing-Angriffen 22 Abb. 3.5.: Graphische Ausgabe des Prototypen. Messungen schreiben zu lassen, in der URL, verwendeter Parameter und Wert des Parameter aufgelistet werden. Zudem können die Zeitmessungen und die Ausgabe, ob diese Anfrage blockiert oder nicht blockiert wurde, mit ausgegeben werden. Wichtig dabei ist, dass solche Ausgaben erst gestartet werden, wenn die Messungen fertig sind, da sonst die Messergebnisse beeinflusst werden könnten Fingerprinting mit Cross-Site Timing-Angriffen Der Cross-Site Timing-Angriff (Kapitel 2.1.2) könnte das Fingerprinting von WAF-Filterregeln durch Timing-Seitenkanäle wesentlich verschärfen. Beim Fingerprinting werden zwar nur Zeiten gemessen, aber die Angriffe werden direkt an den Webserver geschickt. Somit ist das Abtasten der Filterregeln strafbar, da richtige Angriffe in den Parametern an die Web-Anwendung übermittelt werden. Bei dem Cross-Site Timing-Angriff wird, wie bereits in vorherigen Kapiteln beschrieben, eine weitere Person mit in den Angriff einbezogen. Die weitere Person ruft unwissentlich eine Webseite auf, die einen solchen Cross-Site Timing-Angriff beinhaltet. Im Hintergrund läuft nun die Zeitmessung des Fingerprintings. Der Angreifer lässt sich die Ergebnisse einfach von dieser Person übermitteln. Somit lässt sich der Angriff von einer weiteren Person fahren, deren IP-Adresse später in den Log-Files der WAF erscheint. Sollte eine Zeichenkette in dem Fingerprinting der WAF-Filterregeln nicht blockiert werden und auf der Web-Anwendung Schaden verursachen, sowie der reine Versuch, solche Angriffe zu starten, kann strafrechtliche Folgen haben, siehe 303b StGB (Computersabotage).

30 4. Fingerprinting am Beispiel PHPBB Während dieser Bachelorarbeit wurde ein Prototyp entwickelt, der automatisiert WAF- Filterregeln über Timing-Seitenkanäle herausfinden kann. Der Praxis Test soll zeigen, wie gut der Prototyp die WAF-Filterregeln erkennt und ob dieser Weg praktikabel ist. Die verwendete Web-Anwendung phpbb hat keine weitere Funktion als hinter der WAF zu stehen. Der Prototyp soll die kostenlose Kommunikationsplattform phpbb (phpbb 2007) nicht konkret angreifen, es soll lediglich gezeigt werden, wie das Fingerprinting der WAF- Filterregeln über Timing-Seitenkanäle funktioniert. Die Web-Anwendung besitzt keine bekannten Schwachstellen, die angegriffen werden sollen. Der Prototyp ist auf jede Web-Anwendung anwendbar, solange eine WAF existiert und ein Zeitunterschied messbar vorhanden ist. Somit ist die Web-Anwendung für diesen Test unwichtig. Allerdings, kann es zu Unterschieden in den Web-Anwendungen kommen. Der Prototyp misst die Antwortzeit des Webservers, so eignen sich besonders Web- Anwendungen, die für jeden URL-Pfad der Web-Anwendung einen Webseiten Inhalt laden. Eine völlig leere Webseite kann die Messergebnisse wesentlich beeinflussen, da eine inhaltlich leere Webseite im Test viel schneller lädt als eine volle Webseite. Damit unterscheidet sich eine solche Webseite von der Ladezeit nicht mehr erheblich von der Ladezeit einer Fehlermeldung von der WAF und kann so zu falschen Auswertungen der Messergebnisse führen. Es kommt vor allem darauf an, wann der Fehler im Skript der Web-Anwendung auftritt und zu einer inhaltlich leeren HTML-Seite führt. Die Fehlermeldung der Web- Anwendung kann am Anfang im Skript der Web-Anwendung auftreten, dann sind die Zeitunterschiede von blockierten und nicht blockierten Anfragen geringer als wenn eine Fehlermeldung am Ende des Skriptes auftritt. Der Webserver braucht in diesem Fall mehr Zeit zum Lesen des kompletten Skriptes Testumgebung Der Prototyp soll die Methode des Fingerprintings durch Timing-Seitenkanäle umsetzen und zeigen wie gefährlich diese Sicherheitslücke sein kann. Während des Praxistest werden nur die GET-Parameter der Anwendung phpbb berücksichtigt. So lassen sich 4797 zu testende Anfrage-Kombinationen aus URL, Parameter und Anfrage bilden. Für jede dieser Anfrage-Kombinationen muss entschieden werden, ob diese von der WAF blockiert oder nicht blockiert wird. Der Prototyp misst hierzu jede Anfrage-Kombination bis zu 23

31 4.1. Testumgebung 24 5 Mal. Bei einer Anfrage, die 3 Mal unter dem Grenzwert liegt, wird diese als blockiert deklariert. Durch das additive Rauschen, kann davon ausgegangen werden, dass es sich bei dieser Anfrage-Kombination, um eine von den WAF-Filterregeln blockierte Anfrage handelt. Der Prototyp wird dann die nächste Anfrage-Kombination testen. Um die Zeitunterschiede des Timing-Seitenkanals besser darstellen zu können, wurden im Praxis Test alle 5 Anfragen pro Anfrage-Kombination gespeichert. Die Grafiken beinhalten also alle 5 Anfragen pro Anfrage-Kombination, was einer Anzahl von Zeitmessungen entspricht. Zum Testen des Prototyps wurde in dem Praxis Test eine Ausgabe eingeführt, die zurückgibt, welche Anfragen zu einer Fehlermeldung geführt haben. Damit kann eine Fehlerquote in den einzelnen Praxis Tests ermittelt werden. Im Folgenden werden, nachdem die Testumgebung des Praxis Tests erläutert wurde, die Messergebnisse vorgestellt. Außerdem können die Messergebnisse und der Output des Prototypen auf den DVDs des Anhangs C.1 begutachtet werden Testaufbau Um die Messungen mit dem entwickelten Prototyp durchzuführen, bedarf es mehrere Webserver. Auf diesen Webservern wurden die 2 Szenarien, die in Kapitel beschrieben werden, sowie das in Kapitel beschriebene Szenario installiert. Zudem wurde ein Rechner benötigt, von dem aus die Messungen, mit dem Prototyp, durchgeführt werden konnten. Da nicht genügend Server zum Aufbau der 3 Szenarien zur Verfügung standen, Abb. 4.1.: Testaufbau mit OVH Cloud. wurden die Webserver allesamt in der Cloud betrieben. Als Cloud Anbieter wurde der französische Anbieter OVH (OVH.de 2011) gewählt. Zur Anwendung sind minicloud Instanzen mit 5 GHz Prozessorleistung gekommen. Jede Instanz ist mit 265MB Ram und

32 4.1. Testumgebung MB SWAP auf SSD ausgestattet gewesen. Die Messungen wurden von einem Computer aus dem Universitätsnetz durchgeführt. Hierbei handelte es sich, um einen Intel Pentium 4 Prozessor mit 3,2 GHz Rechenleistung und 1GB Ram. Der genaue Aufbau kann Abb. 4.1 entnommen werden. Auf den im Anhang C.1 befindlichen DVDs befinden sich Virtuelle Maschinen, die eine identische Installation beinhalten wie die in der OVH Cloud betrieben Webserver verwendete Filterregeln Für das Fingerprinting von WAF-Filterregeln müssen Filterregeln definiert sein. Diese Filterregeln können manuell definiert werden. Allerdings bringen WAFs meist eigene Filterregeln mit, die von dem Benutzer aktiviert werden können. Die WAF ModSecurity bringt Basis und Optionale Filterregeln mit. Im Praxis Test wurden allerdings nur die Basis Filterregeln aktiviert. Bei der WAF PHPIDS wurde ebenfalls der unveränderte Standardregelsatz verwendet. Der Standardregelsatz von PHPIDS besitzt andere Filterregeln als die Basis Filterregeln der WAF ModSecurity. Daher kommt es zu Abweichungen zwischen den geblockten Angriffen von PHPIDS und ModSecurity verwendete Zeichen und Zeichenketten In diesem Kapitel werden nun die Zeichen und Zeichenketten für den Praxis Test definiert. Dabei wird wie in Kapitel beschrieben, zwischen Listen für Zeichen und Zeichenketten unterschieden. Der Benutzer kann die Zeichenketten in eine dafür vorgesehene Datei schreiben, dabei muss er nicht auf eine Reihenfolge achten. Der Prototyp sortiert sich die zeilenweise eingelesenen Codefragmente der Zeichenlänge nach. In dieser Bachelorarbeit wird eine kleine Auswahl an bekannteren Angriffsmöglichkeiten verwendet. Die Listen können allerdings vom Benutzer des Prototypen variabel erstellt werden und beliebig erweitert werden. Somit kann ein Angreifer gezielt Schwachstellen von WAF-Filterregeln suchen. Die komplette Liste der verwendeten Zeichen und Zeichenketten kann in Anhang A.1 nachgeschlagen werden. SQL-Injection Bei SQL-Injection Angriffen (Kap ) wird versucht in der Web-Anwendung verwendete SQL-Befehle abzuändern. Ein Angreifer kann, wenn er die Namen der Datenbank kennt und die SQL-Befehle nicht validiert werden, ganze Datensätze ändern oder löschen. Eine mögliche Liste an Zeichen, die für SQL-Injection Angriffe benötigt werden, wäre: {, =, >, <, -, #, ;}. Für die weiteren Tests können nun Zeichenketten definiert werden. Dabei können sowohl Worte und kleine Codefragmenete wie z.b. {or, and, DELETE, SE- LECT, admin, --, 1=1} als auch lange fertige Angriffe wie z.b. {admin --, or 1=1--,

33 4.1. Testumgebung 26 ; DELETE Orders;--, or 0=0 # } getestet werden. Cross-Site Scripting Bei XSS Angriffen (Kap ) wird versucht den Quellcode einer Webseite zu verändern. Der Angreifer kann so, die Web-Anwendung beeinflussen oder den Benutzer im Hintergrund auf fremde Webseiten leiten. Dafür werden vor allem typische Ausdrücke aus der Skriptsprache JavaScript gebraucht. Häufige Zeichen die getestet werden sollten wären z.b.: {<, >, /, ; }. Für die Zeichenketten sollten dann einzelne Codefragmente wie {<script>, IMG, </script>, document.cookie, %3cscript%3e, alert, %3c%2fscript%3e} getestet werden. Danach können dann richtige Angriffe wie {<IMG SRC=javascript:alert( XSS )>, <SCRIPT SRC= </SCRIPT>, <IMG SRC=JaVaScRiPt:alert( XSS )>} geprüft werden. Directory Traversal Bei Directory Traversal Angriffen (Kap ) handelt es sich um eine Pfadänderung der URL. Meist wird hier mit Verzeichnissnamen und dem Wechsel auf höhere oder niedrigere Verzeichnisse gearbeitet. Deshalb sollten Verzeichnisse wie /etc oder C: auch in der zu testenden Liste vorkommen. Benötigte Zeichen für Directory Traversal wären {C, :,., \, /, %}. Als kurze Zeichenketten können dann Codefragmente wie {C:,.., /etc/,..\,../ } getestet werden und als längere Zeichenketten {../../../passwd, /%2e%2e%2f,../..//../..//./(FileName)} ermitteln der verwendeten Parameter Die Filterregeln der WAF können für jeden Parameter unterschiedlich definiert sein, daher sollte das Fingerprinting alle Parameter testen. Für diesen Prototyp werden, die GET- Parameter der Web-Anwendung geprüft. Das Prinzip ist für die POST-Parameter das gleiche, nur müssen diese aus jedem HTML-Skript in der Web-Anwendung gefiltert werden. Da jede URL verschiedene Parameter nutzen kann, sollten die in einer URL vorkommenden GET-Parameter alle mit dieser URL und den einzelnen Anfragen kombiniert werden. Die in der Web-Anwendung vorkommenden URLs können mit einem Crawling gefunden werden. Das Crawling einer Webseite ist einfach zu implementieren, aber schwierig effizient durchzuführen (Abello et al. 2002). Der Prototyp verwendet eine PHP Crawling Bibliothek (PHPCrawl 2011), mit der weitere URLs des eingegebenen URL-Pfades gefunden werden können. Dabei sollte bei der Speicherung der Crawling Ergebnisse darauf geachtet werden, dass Duplikate vermieden werden, um keine unnötigen Zeitmessungen durchzuführen.

34 4.2. Installation in der demilitarisierten Zone 27 Für die Ermittlung der Parameter nimmt der Prototyp die Ergebnisse aus dem PHP Crawling. Die Bibliothek gibt die Möglichkeit den Query String auszugeben oder zu speichern. Dieser Query String ist der Teil in der URL, indem Parameter und Wert des Parameters enthalten sind. Parameter&parameter2=Wert Parameter In diesem Beispiel ist der Query String der Teil ab einschließlich dem Fragezeichen. Es befinden sich zwei Parameter in der URL, die der Web-Anwendung übergeben werden. Diese Parameter werden beide für den Prototyp benötigt. Also schneidet der Prototyp den Query String so zurecht, dass parameter und parameter2 gespeichert werden können. Diese beiden Parameter werden dann mit passendem URL-Pfad gespeichert. Beim Fingerprinting werden diese Parameter einzeln auf diese URL getestet. Der Wert der Parameter entspricht dann den Zeichen und Zeichenketten, die getestet werden sollen, die in Kapitel beschrieben werden Installation in der demilitarisierten Zone Bei der Installation der WAF in der demilitarisierten Zone sind die besten Messergebnisse zu erwarten, da dort wie in Kapitel beschrieben, der längste Weg zwischen WAF und Web-Anwendung vorhanden sein sollte. Als erstes ermittelt der Prototyp einen Grenzwert Abb. 4.2.: Installation in der demilitarisierten Zone: Erster Test und Grenzwert. für das weitere Fingerprinting. Der errechnete Grenzwert beträgt CPU Takte.

35 4.2. Installation in der demilitarisierten Zone 28 Umgerechnet in Millisekunden entspricht dieser Wert ungefähr 69,85 Millisekunden. Alle Zeitmessungen, die eine niedrigere Antwortzeit besitzen, werden als blockierte Anfrage deklariert. Der Grenzwert wurde wie in Kapitel errechnet. Auf der Abb. 4.2 sind die Ergebnisse des ersten Testes einzusehen. Der Zeitunterschied zwischen blockierenden und nicht blockierenden Anfragen ist deutlich sichtbar und beträgt ungefähr 62,63 Millisekunden. Allerdings gibt es einen Ausrutscher in den invaliden Anfragen, bei dem die Zeitmessung sehr viel Rauschen hat und somit näher an den Zeitmessungen von den validen Anfragen liegt. Dieser Ausrutscher wird mit weiteren 9 Messwerten als Ausschuss der invaliden Anfragen bezeichnet. Dieser Ausschuss entspricht den 10 Werten, die durch das 0,9-Quantil ausgeschlossen werden. Damit errechnet sich der Grenzwert und in der Grafik erscheint dieser in der Mitte des Zeitunterschiedes. Abb. 4.3.: Installation in der demilitarisierte Zone: Fingerprinting Zeitmessung. Für den Praxis Test wurde die Fehlermeldung ebenfalls vom Prototyp gespeichert, damit eine Fehlerquote ermittelt werden konnte. Im Test wurden 4797 Kombinationen aus URL, Parameter und Angriff getestet. Dabei wurden 236 Anfragen falsch deklariert. Dies ergibt eine Fehlerquote von 4,92%. Damit ist die Zeitmessung durchaus einsetzbar zum Fingerprinting von WAFs. Bei kritischem Betrachten der Fehler, kann festgestellt werden, dass 196 Fehler in den Zeitmessungen einer bestimmten URL stattfanden. Die Seite hinter der URL hat nur mit einem bestimmten Inhalt eines Parameters eine Ausgabe und bricht die Ausführung ansonsten schnell ab. Somit kann davon ausgegangen werden, dass die Fehler aufgetreten sind, weil der Grenzwert einfach zu groß für diesen einen URL-Pfad war. Die gesamten Ergebnisse sind in der Abb. 4.2 veranschaulicht. Dabei sind alle 5 Zeitmessungen pro Anfrage-Kombination in die Grafik eingetragen. Sobald 3 Zeitmessungen unterhalb

36 4.3. Installation auf dem Webserver 29 des Grenzwertes liegen, wird diese Anfrage als invalide Anfrage deklariert. Deutlich zu erkennen ist der Zeitunterschied der zwischen den validen und invaliden Anfragen entstanden ist. Der Prototyp gibt nachdem er alle Messungen von jeder Zeichenkette auf jeden Parameter durchgeführt hat, eine HTML-Seite aus, in der alle nicht blockierten Anfragen aufgelistet werden. Ein Auszug von diesem Output kann in Anhang B.1 begutachtet werden und das komplette Ergebnis befindet sich auf den beigelegten DVDs. Für einen Angreifer bedeutet das Fingerprinting, dass zum Beispiel eine Schwachstelle in den WAF-Filterregeln für den Parameter sid auf den URL-Pfad phpbb/index.php, der Angriff or a=a - - nicht blockiert wird. Das ist eine von dem Prototyp entdeckte Schwachstelle in den WAF-Filterregeln für diesen Parameter und dessen URL-Pfad. Mit etwas Glück ist ein Angriff auf die Web- Anwendung über diese Schwachstelle in den WAF-Filterregeln möglich. Dafür müsste die Web-Anwendung auch eine Schwachstelle an dieser Stelle für diesen Parameter, URL-Pfad und Angriff haben Installation auf dem Webserver Der zweite Praxis Test ist nun anhand von einem Apache Webserver mit installiertem phpbb und ModSecurity enstanden. Die Umgebung wird in Kapitel erläutert. Wenn ModSecurity auf dem gleichen Webserver installiert ist, wie phpbb auch, wird der Weg zwischen WAF und Web-Anwendung verkürzt. Der Praxis Test wiederlegt allerdings, die Abb. 4.4.: Installation auf dem Webserver: Erster Test und Grenzwert.

37 4.3. Installation auf dem Webserver 30 Annahmen in Kapitel Der Zeitunterschied wurde nicht geringer sondern größer als der Zeitunterschied in dem vorherigen Praxis Test in Kapitel 4.2.Deshalb ist das Ergebnis schwer zu beurteilen. Die Zeitmessungen des zweiten Praxis Tests ergeben einen höheren Grenzwert mit CPU Takten, was ungefähr 79,21 Millisekunden entspricht. Auf Abb. 4.4 wird der erste Test im zweiten Praxis Test veranschaulicht. Die errechnete untere Grenze, das 0,9 Quantil unterscheidet sich mit dem in Kapitel 4.2 errechneten 0,9 Quantil gerade Mal um 0,25 Millisekunden. Somit lagen die invaliden Anfragen ungefähr im selben Bereich wie die invaliden Anfragen des ersten Praxis Tests. Die Zeitmessungen der validen Anfragen sind an dem höheren Grenzwert schuld. Die validen Anfragen haben mehr Zeit benötigt als im vorherigen Test. Dadurch wurde der Zeitunterschied zwischen den blockierten und nicht blockierten Anfragen höher. Zu erwarten war, dass der Zeitunterschied geringer werden würde. Doch der errechnete Zeitunterschied beträgt ungefähr 81,86 Millisekunden. Die Zeitmessungen des Fingerprintings sind mit einem eindeutigen Zeitunterschied zwischen validen und invaliden Anfragen ausgefallen, wie in Abb. 4.5 gezeigt. Abb. 4.5.: Installation auf dem Webserver: Fingerprinting Zeitmessung. Die Messungen haben mehr Rauschen wie im ersten Praxis Test, aber haben eine geringere Fehlerquote mit 4,79% aufzuweisen. Der Prototyp konnte durch den höheren Zeitunterschied etwas bessere Ergebnisse erzielen. Die beiden Praxis Tests zeigen, dass der Prototyp in beiden Installationsoptionen von ModSecurity zur Abtastung von WAF-Filterregeln einsetzbar ist. Der Zeitunterschied ist in beiden Varianten groß genug, um invalide Anfragen von validen Anfragen zu unterscheiden.

38 4.4. PHPIDS PHPIDS Im letzten Praxis Test wird der Prototyp anhand der WAF Bibliothek PHPIDS getestet. Der Aufbau dieser Umgebung kann in Kapitel nachgeschlagen werden. Der errechnete Grenzwert in diesem Praxis Test beträgt CPU Takte, was ungefähr 89,21 Millisekunden entspricht. Somit liegt der Grenzwert weit über dem Grenzwert aus den ersten beiden Praxis Tests. Auf der Abb. 4.6 kann der deutliche Zeitunterschied zwischen validen und invaliden Anfragen begutachtet werden, der auch bei diesem Praxis Test vorhanden ist. Die Zeitmessungen der invaliden Anfragen besitzen in diesem Praxis Test ein höheres Rauschen. Trotzdem wurde die Berechnung des Grenzwertes noch nicht gestört und der Ausschuss über das 0,9-Quantil reichte für diesen Praxis Test gerade noch aus. Bei mehr Rauschen sollte der Grenzwert mehr Messwerte von invaliden Anfragen aus der Berechnung des Grenzwertes aussortieren. Der Zeitunterschied beträgt in diesem Praxis Test ungefähr 48,22 Millisekunden. Somit wird der in Kapitel erwartete kürzerer Zeitunterschied bestätigt. Die Zeitmessungen des Fingerprints ergeben eine etwas höhere Abb. 4.6.: PHPIDS: Erster Test und Grenzwert. Fehlerquote mit ungefähr 5%. Die Messergebnisse schwanken stärker als in den beiden anderen Messergebnissen, wie in Abb. 4.7 zu sehen ist. Da PHPIDS andere Filterregeln als ModSecurity verwendet, sind die Einschätzungen der Messergebnisse an manchen Stellen unterschiedlich zu den Einschätzungen in den beiden vorherigen Praxis Tests. Trotz der leicht höheren Fehlerquote und dem kleineren Zeitunterschied kann die Methode über Timing-Seitenkanäle WAF-Filterregeln abzutasten noch brauchbare Ergebnisse bringen.

39 4.4. PHPIDS 32 Abb. 4.7.: PHPIDS: Fingerprinting Zeitmessung.

40 5. Diskussion In diesem Kapitel soll die Methode des Fingerprintings von WAF-Filterregeln über Timing- Seitenkanäle ausgewertet werden. Zum einen sollen hier mögliche Probleme, die während des Fingerprintings auftreten können, erläutert werden. Zum anderen soll ein Ausblick in die Zukunft beschreiben, wie diese Methode ausgeweitet werden könnte. Einige Verbesserungsvorschläge könnten in Zukunft diese Art von Fingerprinting der WAF-Filterregeln praktikabler werden lassen und zu besseren Ergebnissen führen Aufwand und Probleme Die Methode über Timing-Seitenkanäle WAF-Filterregeln zu ertasten, kann in erster Linie von dem Messumfeld erschwert werden. Das Rauschen der Antwortzeiten kann die Ergebnisse der Zeitmessungen deutlich abändern und zu anderen Ergebnissen im Fingerprinting führen. Dieses Rauschen ist leider nicht zu beeinflussen und kann wie in Kapitel 4.3 auch mal zu unerwarteten Ergebnissen führen. Dabei kommt es darauf an, welche Tätigkeiten ein Webserver während der Messungen durchführt und in welchem Internetnetz dieser sich befindet. Ein weiterer Faktor, der die Messergebnisse beeinflussen kann, ist die Web-Anwendung selbst. Sobald der Grenzwert nur ein einziges Mal während des Programverlaufs ermittelt wird, kann es dazu kommen, dass der Grenzwert nicht auf alle URL-Pfade passt. Dies kann zu falschen Ergebnissen führen. Wobei die Fehlerquote in den Praxis Tests trotzdem noch gering ausfiel. Die Schwierigkeit beim Fingerprinting von WAF-Filterregeln liegt eindeutig darin, dass zu prüfende Zeichen und Zeichenketten definiert werden müssen. Dies kann sehr aufwendig sein und man benötigt ein gutes Wissen über Angriffsvariationen. Das Fingerprinting benötigt viele Messergebnisse und damit viel Zeit. Ein Cross-Site Timing-Angriff wird dadurch erheblich erschwert, da ein Benutzer lange genug, auf der böswilligen Webseite verbringen müsste, damit alle Zeitmessungen durchgeführt werden könnten. Daher eignete sich, der Angriff über einen Cross-Site Timing-Angriff nur bei einem sehr gezielten Fingerprinting. 33

41 5.2. Ist diese Methode sinnvoll? Ist diese Methode sinnvoll? Der Timing-Seitenkanal stellt eine gute Hintertür da, um WAF-Filterregeln zu ermitteln. Das Schreiben von Angriffen auf eine Web-Anwendung kann begünstigt werden, durch das Wissen über von der WAF blockierte und nicht blockierte Zeichenketten, denn es muss zuerst eine Schwachstelle in den Filterregeln der WAF gefunden werden. Der Angriff ist nach dem Fingerprinting von den WAF-Filterregeln schneller zu tätigen und erspart jede Menge blindes ausprobieren. Gerade die Tatsache, dass Fehlermeldungen von der WAF und von der Web-Anwendung das gleiche Aussehen vorzeigen können, erschwert den Angriff enorm. Der Angriff kann nur blind ertastet werden. Im Allgemeinen ist das Messen von Antwortzeiten eines Webservers relativ einfach zu implementieren, wie in Kapitel gezeigt, ist die eigentliche Messmethode gut überschaubar. Die Messergebnisse aus dem Praxis Test in Kapitel 4 zeigen, wie die Zeitmessungen den Zeitunterschied zwischen blockierten und nicht blockierten Anfragen beinhalten. Dabei wurden die Messergebnisse, der in der demilitarisierten Zone liegenden WAF, wesentlich deutlicher als die beiden anderen Messergebnisse. Es war weniger Rauschen in den Messergebnissen vorhanden. Die Methode über Timing-Seitenkanäle WAF-Filterregeln abzutasten eignet sich für alle drei Varianten gut, da messbare Zeitunterschiede in allen drei Varianten sichtbar waren. Die Fehlerquote in allen drei Praxis Tests liegt sehr nah bei einander und zeigt, dass die Methode trotz der unterschiedlichen Installationen zuverlässig funktioniert. Der Prototyp errechnet am Anfang des Testverlaufes einen Grenzwert, der für das gesamte Programm verwendet wird. Dabei werden URL-Pfad und ein dazu gehöriger Parameter benötigt, die durch den Benutzer angegeben werden können. Der Wert des Parameters sollte einmal eine von der WAF nicht blockierender Inhalt und zum anderen ein blockierender Inhalt sein. Der Grenzwert ist somit passend für genau diese URL mit diesem eingegebenen Parameter. Im späteren Testverlauf wird ein PHPCrawling durchgeführt, bei der URL-Pfade mit ihren möglichen Parametern ermittelt werden. Auf diese URL-Pfade könnte nun der Grenzwert nicht hundertprozentig passen. Eine Berechnung des Grenzwertes je URL-Pfad könnte dann Abhilfe schaffen, wobei ein weitaus größerer Overhead entstehen würde und es wäre zu erwarten, dass die Messergebnisse genauer werden. Zum anderen kann der Prototyp keine Zeichen und Zeichenketten streichen, da er diese nur einmal im Programmverlauf speichert. Als Weiterentwicklung wäre es möglich, die Zeichen und Zeichenketten für einen Parameter zu definieren, damit Zeichen und Zeichenketten, die nicht mehr geprüft werden müssen, gestrichen werden können. Blockierte Codefragmente würden dann nicht mehrmals geprüft werden, denn die Filterregeln blockieren ein blockiertes Codefragment auch als Teil eines anderen Codefragmentes. Somit

42 5.2. Ist diese Methode sinnvoll? 35 können Codefragmente, die bereits als blockiert deklarierte Codefragmenente enthalten, ebenfalls als blockiert markiert werden. Die Zeitmessung ist für solche Codefragmente überflüssig und es könnte die Anzahl an Zeitmessungen im Programmverlauf reduziert werden. Dies soll nur eine Auswahl an Möglichkeiten darstellen, die noch zur Verbesserung des Prototypen in Frage kommen könnten. Gerade die Praxis Tests zeigen, wie gut der Zeitunterschied zwischen blockierten und nicht blockierten Anfragen ersichtlich ist. Um Web-Anwendungen weiterhin gut schützen zu können, sollte weiter auf diesem Gebiet geforscht werden. Gerade im Bereich des Timing-Seitenkanals gibt es noch erhebliche Sicherheitslücken, deren Ausnutzen zumindest erschwert werden sollte. Gerade für Administratoren und Hersteller von WAFs heißt dies, dass Filterregeln abgetastet werden können und somit nicht geheim bleiben.

43 6. Fazit Die Methode über Timing-Seitenkanäle WAF-Filterregeln abzutasten ist eine gute Möglichkeit, gezielt nach Schwachstellen in den Filterregeln zu suchen. Allerdings, gibt es einige Aspekte, die dabei beachtet werden sollten. Wie im letzten Kapitel beschrieben, sollte das Fingerprinting eher gezielt eingesetzt werden, da durch eine einmalige Ermittlung des Grenzwertes Fehler auftauchen könnten. Das Fingerprinting ist eher einfach zu implementieren und die Schwierigkeit dieser Methode liegt in der Ermittlung der Zeichen und Zeichenketten, sowie in der Ermittlung der Parameter einer Web-Anwendung. Die Auswertung der Zeitmessungen wird über das Programm selbst gelöst und die Ausgabe zeigt, welche Angriffe auf eine Web-Anwendung möglich sind. Das Ausnutzen eines Timing-Seitenkanals zum Ertasten von WAF-Filterregeln kann einem Angreifer, die Vorbereitungen zu einem Angriff erleichtern. Jedoch sollte bei der Auswertung der Zeitmessungen eine kritische Haltung eingenommen werden. Damit es die Chance gibt, die Ergebnisse besser zu interpretieren. Ein großes Rauschen in den Messergebnissen kann Ergebnisse verfälschen oder es zumindest erschweren das Fingerprinting durchzuführen. Sollte der Grenzwert nur einmal im Fingerprinting errechnet werden, so könnten hier Fehler entstehen, indem der Grenzwert nicht auf die anderen URL-Pfade passt. Ebenso könnte bei der Berechnung des Grenzwertes ein Rauschen der invaliden Anfragen, das 0,9 Quantil überschreiten und so zu einem unsinnigen Grenzwert führen. In diesem Fall wären alle Messergebnisse falsch interpretiert. Somit sollte der Benutzer des Prototypen, die Berechnung des Grenzwertes dynamisch an die Web-Anwendung anpassen, sobald ein höheres Rauschen eintritt. Zusammenfassend ist der Prototyp ein gutes Werkzeug, um WAF-Filterregeln zu ertasten. Allerdings, sollte das Rauschen in den Messergebnissen beachtet werden und gegebenenfalls der Prototyp an die einzelne Web-Anwendung angepasst werden. Somit entsteht ein Werkzeug, das nur in qualifizierten Händen zu guten Ergebnissen führen kann. 36

44 A. Anhang A.1. Definition Zeichen und Zeichenketten A.1.1. SQL-Injection A Zeichen A Zeichenketten VIII

45 A.1. Definition Zeichen und Zeichenketten IX A.1.2. Cross-Site Scripting A Zeichen A Zeichenketten