Sicherheitsanalyse Webserver

Danksagung

Auch an dieser Stelle möchte ich persönlich darauf hinweisen, dass trotz der Kritik die sowohl kommerziell Softwarehersteller und auch Open Source Entwickler laufend von allen Seiten hinnehmen müssen, die Produkte Internet Information Server und Apache ganz ausgezeichnete sind. Ich kenne selbst noch die Zeit, wo ein Viruskiller die einzige Sicherheitsmaßnahme am Rechner war und auch die ersten Versionen von Windows (DOS), Apache und IIS. Anwender verwünschen oft die Hersteller für deren Entwicklungen, Fehler der Software, Abstürze usw., vergessen aber meiner Meinung nach häufig, dass wenn man die Komplexität der Software heranzieht, es bereits unglaublich ist, dass ein Computer überhaupt bootet. Wenn man die Softwareprodukte im Laufe der Zeit vergleicht und beobachtet, kann man leicht entdecken, dass die Komplexität ständig zunimmt, aber trotzdem Millionen Benutzer ein verwendungsfähiges System vor sich haben.

Persönlich danke ich meinem Betreuer DI. Rainer Schmidt für seine Inputs zu den einzelnen Themen. Sein Fachwissen selbst zu tiefgehenden Themen hat mich bei jedem Gespräch aufs Neue beeindruckt.

Weiters danke ich meinem persönlichen Freund MBA Werner Kölbl für seine kreativen Anmerkungen und seine technische Unterstützung.

Darüber hinaus danke ich dem Team meines Studiengangs für die umfassende und interessante Ausbildung.

Last but not least danke ich meinem persönlichen Freundeskreis für die Geduld, die Unterstützung und das aufgebrachte Verständnis während meines Studiums und während der Erstellung dieser Arbeit.

Reinhard Hofer

30.05.2006

Reinhard Hofer

Sicherheitsanalyse Webserver

Kurzfassung Deutsch

Die Diplomarbeit setzt am Punkt Internet an, dem zentralen Werkzeug zur Kommunikation bzw. Informationsbeschaffung. Da das Thema Internet und auch Sicherheit ein sehr umfangreiches ist, spezialisiert sich die Arbeit auf die Server, die hinter dem Webseiten stehen und von alltäglichen Benutzern nicht wahrgenommen werden. Es ist nicht Ziel dieser Arbeit, sonstige Bereiche der Kommunikation, Sicherheit, Internet oder Plattformen zu behandeln. Es ist weiters nicht Ziel, neue Sicherheitslöcher in Webserverprodukten aufzudecken oder detailliert auf Mittel und Wege hinzuweisen, Webserver oder Webseiten zu kompromittieren. Sehr wohl ist aber wichtig, nicht nur die Server selbst zu untersuchen, sondern auch grundsätzlich die Clientseite und hier im Speziellen den Sourcecode zu erklären.

Die Arbeit ist in drei Abschnitte unterteilt. Der einleitende Abschnitt beinhaltet Theorie zu gängigen Angriffsformen auf Webserver und Webseiten und beinhaltet damit auch gängige Formen zum widerrechtlichen Erlangen von Passworten oder zum Umgehen von passwortgeschützten Techniken. Zusätzlich zum theoretischen Ansatz beinhaltet dieses Dokument Beispiele für mögliche Techniken und deren Schwachstellen. Im Sourcecode-Abschnitt wird gezeigt, wie man den Zugang zu Webserverressourcen beschränken kann und worauf man dabei achten muss bzw. wo und wie Angreifer ansetzen können. Dazu gibt es mehrere Beispiele, die an Komplexität zunehmen und aufsteigend angeführt werden.

Die beiden anderen Abschnitte behandeln die beiden Webserver Internet Information Server 6 und Apache 2.2 und sind gleich aufgebaut und zeigen eine vergleichende Sicht auf das jeweilige Produkt. Im Vordergrund steht auch hier der Sicherheitsaspekt. Welche Schwachstellen weist das jeweilige System auf und wie kann man sich schützen? Die Beschreibung der Konfiguration bzw. der Schritte zur Absicherung des Systems zeigen auch, wo die jeweiligen Schwachstellen liegen und welcher Konfigurationsaufwand dabei entsteht. Das Abschlusskapitel zeigt die resultierenden Ergebnisse.

Reinhard Hofer

Sicherheitsanalyse Webserver

Kurzfassung Englisch

Security is no longer about a second lock for your door or about buying an alarm system. Today’s networking and the geographical extension of computers and Internet leads to new security threats. The Internet is today’s centre of communication and information gathering. As web servers are at the centre of almost all online communication and are therefore the centre for security measures, this thesis focuses on the servers which are not visible by common users. The aim of this work is not to explain operating systems, Internet communication, platforms etc. Furthermore, the author doe not intend to discover new security leaks in actual web server software or to explain in detail how to compromise a web server system. That is to say, it takes a look at the clients and explains the source code executed on their side.

The thesis is divided into three sections. The introductory section includes the theoretical background of common attack scenarios on web servers and websites. It also refers to common ways of avoiding or bypassing password protected techniques. In addition to the theoretical part, the thesis includes examples of source code and their weaknesses. This section shows methods to restrict access to resources and describes the possibilities available to hostile users. The complexity of the examples increases and is in ascending order. The examples shown describe client side and server side code and are written in script languages like PHP, JavaScript, VB.(NET) and JSP.

The other sections cover the two web servers that have the largest market share. The chapters about Internet Information Server 6 and Apache 2.2 have the same structure and compare both products. Certainly, security is given priority. Which weaknesses are there and how can one protect oneself? Additionally both chapters mention basic security measures. The explanation of configuration and first steps show the complexity and effort needed. Besides the substantial research the reader can find multiple analyses on network traffic as well as scans of the server systems and a comparison of security holes. The final chapter shows the results.

Reinhard Hofer

  Sicherheitsanalyse Webserver  

Inhaltsverzeichnis

  Seite  

1  Einleitung  1

1.1  Problemstellung  1

1.2  Zielsetzung  2

2  Quellcode  4

2.1  Fehler und Risiken  4

2.2  Passwortgeschützter Zugang  6

2.2.1  HTML und clientseitige Skripte  6

2.2.2  Serverseitige Skripte  7

2.2.3  Referer Header und Cookies  8

2.2.4  Codebeispiele  10

2.2.4.1  Beispiel 1 Sourcecodeanalyse  10

2.2.4.2  Beispiel 2 Sourcefehler  13

2.2.4.3  Beispiel 3 Sessions  16

2.2.4.4  Beispiel 4 Skriptinjections Referer Cookies  16

2.2.4.5  Beispiel 5 Dateien außerhalb des Webverzeichnisses / Includes  19

2.2.4.6  Beispiel 6 SQL-Injections  20

2.3  Angriffsmethoden  26

2.3.1  Spoofing  26

2.3.1.1  Adress Resolution Protocol-Spoofing  27

2.3.1.2  Domain Naming Service-Spoofing  30

2.3.1.3  IP-Spoofing  32

2.3.1.4  Route-Spoofing  35

2.3.2  Denial of Service  36

2.3.2.1  Flooding  36

2.3.2.2  Intern Control Message Protocol - Angriffe  37

2.3.3  Scanning  38

2.3.3.1  Portscanning  38

2.3.3.2  Sniffing  39

2.3.4  Cracking  40

2.3.5  Phishing  42

3  Internet Information Server  45

3.1  Risiken  45

3.2  Standardeinstellungen und Konfiguration  46

3.2.1  Änderungen an den Standardeinstellungen  46

3.2.2  Sicherheitsmaßnahmen  48

3.2.2.1  Sicherheitsrichtlinie  48

3.2.2.2  Logging  49

3.2.2.3  Checkliste  52

3.2.3  Verbesserungen gegenüber IIS 5  54

3.3  Security Analyse  56

3.4  Hotfixes  59

3.4.1  Aktuelle Sicherheitslöcher  59

3.4.1.1  Kompressionsfehler verursacht Zugriffsverletzungen  59

3.4.1.2  Kennwortänderungsseiten  60

  Reinhard Hofer  5

  Sicherheitsanalyse Webserver  

3.4.1.3  WebDAV-XML Message Handler  60

3.4.1.4  FTP-Resume Feature  61

3.4.1.5  ASP NET und Set-Cookie  61

3.4.2  Herstellerverhalten  62

3.5  Systeme die auf den Webserver einwirken  64

3.5.1  Betriebssystem  64

3.5.2  Intrusion Detection System  66

3.5.3  Demilitarized Zone  67

3.5.4  Firewall  69

3.5.5  Viruskiller  71

4  Apache  75

4.1  Risiken  75

4.2  Standardeinstellungen und Konfiguration  76

4.2.1  Änderungen an den Standardeinstellungen  76

4.2.2  Sicherheitsmaßnahmen  77

4.2.2.1  Logging  77

4.2.2.2  Checkliste  79

4.2.3  Verbesserungen gegenüber Apache 1 3 bzw. 2 0  81

4.2.3.1  Verbesserungen von Apache 2 0 gegenüber 1 3  81

4.2.3.2  Verbesserungen von Apache 2 2 gegenüber 2 0  82

4.3  Securityanalyse  83

4.4  Updates  85

4.4.1  Aktuelle Sicherheitslöcher  85

4.4.1.1  Referer Cross-Site Scripting  85

4.4.1.2  Behobene Sicherheitslöcher in Version 2 0 58  85

4.4.1.3  Behobene Sicherheitslöcher in Version 2 0 55  86

4.4.2  Herstellerverhalten  86

4.5  Systeme die auf den Webserver einwirken  88

4.5.1  Betriebssystem  88

4.5.2  Intrusion Detection System  89

4.5.3  Demilitarized Zone  89

4.5.4  Firewall  89

4.5.5  Viruskiller  89

5  Ergebnisse und Schlussfolgerungen  90

6  Zusammenfassung  96

7  Verzeichnisse  98

7.1  Literaturverzeichnis  98

7.2  Abbildungsverzeichnis  101

7.3  Tabellenverzeichnis  102

7.4  Listingverzeichnis  102

7.5  Formelzeichen, Indizes und Abkürzungen  103

  Reinhard Hofer  6

Sicherheitsanalyse Webserver

1 Einleitung

1.1 Problemstellung

Bereits der Amerikaner Abraham H. Maslow hat in seinem Studium über die Bedürfnisse der Menschen Sicherheit als wesentlichen Bestandteil aufgenommen. Genauer ist in seiner „Hierarchy of the prepotency of human needs“, übersetzbar mit Bedürfnispyramide, der Punkt Sicherheit auf Stufe 2 und somit unmittelbar nach den Grundbedürfnissen. Sicherheit ist ein Begriff der viele Aspekte im Leben und in der Gesellschaft vereint und eine Möglichkeit zum Befriedigen des Sicherheitsbedürfnisses ist Vorbeugung bzw. Implementierung von Schutzmechanismen.

Betrachtet man das Thema Sicherheit im Rahmen der IT, dann wird deutlich, wie weit verzweigt dieses Thema wirklich ist. IT-Sicherheit war mehr als 20 Jahre nicht von Nöten. Das Urnetz ARPANET war eine Vernetzung von vier Rechnern zwischen Universitäten in den USA. Die Teilnehmer kannten sich untereinander. Das World Wide Web, das 1989 von Cern entwickelt wurde, hat die Situation geändert. Plötzlich war die Allgemeinheit eingebunden und damit das Netzwerk unkontrollierbar. Reichte vor einem Jahrzehnt noch ein guter Virenkiller aus, so ist heutzutage ein ungeschützter Server im Internet innerhalb von Minuten das Opfer irgendeiner Form eines Angriffs.

Von allen Sicherheitsmechanismen wie Intrusion Detection Systems, Honeypots, Sicherheitsrichtlinien usw. ist in dieser Arbeit vor allem die Sicherheit von Webservern im Vordergrund. Ein Webserver steht natürlich nicht auf sich selbst gestellt im Netz. Eine Firewall ist obligatorisch und jedes System, das das Netzwerk bzw. den Server selbst schützt, unterstützt die Sicherheit des Webserver mit. Die Fragen, die sich stellen sind, welchen Webserver man verwenden soll und worauf man achten muss bzw. welche Möglichkeiten man bei der Konfiguration hat. Der heute marktführende Webserver ist Apache, gefolgt vom Internet Information Server. Es gibt weitere Webserver die mitunter spezialisiert in einem

Reinhard Hofer 1

Sicherheitsanalyse Webserver

bestimmten Bereich sind. Tomcat beispielsweise ist weniger ein Webserver, sondern eine Servletengine ¹ . MyServer ist ein weiteres Open Source Project mit GNU General Public License (GPL) oder Zeus stellt einen High Performance Webserver dar. Im Zuge dieser Arbeit werden die beiden wohl bekanntesten, sicher aber wichtigsten Server Apache und IIS evaluiert und verglichen.

1.2 Zielsetzung

Ziel ist, die Risiken beim Einsatz von Webservern aufzuzeigen und auf entsprechende Lösungen hinzuweisen. Die Arbeit beantwortet, welcher Webserver unter welchen Bedingungen der bessere und sichere ist. Dies beginnt bei der Konfiguration, die bei beiden Produkten sehr umfangreich und oft verwirrend ist. Jeder Server hat seine eigenen Schwächen, wobei einige bekannt sind bzw. von den Herstellern behoben, andere nicht. Vor allem die Möglichkeiten zur Beeinträchtigung der Funktionalität und Erlangen von geheimer Information sind wichtig. Welche Möglichkeiten gibt es, sich vor Eindringlingen zu schützen? Welche Risiken bestehen generell? Nicht nur das fertige Endprodukt wird untersucht, sondern auch das Verhalten der Hersteller. Nur Microsoft und die Apache Software Foundation können Sicherheitsmängel beheben. Hier wird untersucht, wie das Verhalten der Hersteller ist und wie schnell aufgedeckte Mängel behoben werden.

Die benutzten Betriebssysteme stehen hier im Hintergrund. Apache läuft zwar auf allen Linuxderivaten und auf Windows, jedoch ist für IIS Windows Voraussetzung. Die Systeme rund um den Webserver stehen im Hintergrund. Selbstverständlich wird auf Entsprechendes hingewiesen, es ist jedoch nicht Ziel dieser Arbeit, die Konfiguration des Netzwerks oder eine Anleitung zur Erstellung von Sicherheitsrichtlinien zu liefern. Noch weniger ist es Ziel eine Anleitung zum Hacken zu liefern. Viel mehr werden Fehler aufgezeigt und die Möglichkeit zur Vermeidung eben dieser.

Ein Kapitel widmet sich dem Sourcecode selbst. Jeder Webserver dient letztendlich nur der Umwandlung der Source in lesbaren Text, d.h. der Ausgabe für den

¹ Eine Servletengine dient zum Ausführen von Programmcode. Im Fall von Tomcat zum Ausführen von Javacode bzw. von Java Server Pages.

Reinhard Hofer 2

Sicherheitsanalyse Webserver

Browser. Der beste Server kann nicht verhindern, dass das Passwort der Seite im Sourcecode steht. Solche Fehler im Sourcecode sind natürlich ebenfalls zu vermeiden.

Reinhard Hofer 3

Sicherheitsanalyse Webserver

2 Quellcode

2.1 Fehler und Risiken

Seit dem Jahr 2000 gibt es einen sprunghaften Anstieg an publizierten Schwachstellen in Soft- und Hardware. Dieser Anstieg korreliert mit einem Anstieg an Sicherheitszwischenfällen, die unter anderem solche Schwachstellen ausnutzen. Weiters muss berücksichtigt werden, dass nicht jeder Zwischenfall erkannt oder gemeldet wird, was die Zahlen noch weiter in die Höhe treibt. Von den finanziellen Kosten her betrachtet, sind Viren und Denial-of-Service - Angriffe die kostspieligsten. Die Gründe hierfür liegen einerseits in der relativ einfachen Verbreitung von Viren und der geringeren Komplexität von Zerstörungsangriffen im Vergleich zu Einbrüchen in Systeme. ² Ein Virus, das sich selbst per Mail verbreitet, indem es sich selbst beim Ausführen an alle Mailkontakte des Mailclients versendet, kann in sehr kurzer Zeit eine hohe Anzahl an Clients infizieren und beinträchtigen. Der sprunghafte Anstieg im Jahr 2000 ist damit allein noch nicht erklärt, vielmehr korreliert dieser Anstieg mit der gestiegenen Anzahl an Computern bzw. Internetanschlüssen. „Die Survival Time eines nicht gepatchen Windows XP PC an einer Auswahl an Breitbandnetzwerken ohne Firewall in einem normalen Betriebszustand betrug im März 2006 mindestens 15 Minuten. Einhergehende Messungen in Kabelnetzen zeigen 50 - 60 Portscans und Einbruchsversuche an einem Anschluss pro Minute.“ ³ Es ist auch interessant, dass laut Sans bei den ersten fünf Schwachstellen bei Windows der Webserver und Services an oberster Stelle steht und bei Unix der Webserver an zweiter Stelle steht. Ein als Teil dieser Arbeit stattgefundener Versuch mit einem gepatchen Windows XP SP 2 Client ohne Firewall an einem Kabelanschluss hatte nach 30 Minuten Surfen im Internet unter dem Administratorkonto das Ad-aware 6.181 -Scanergebnis von 7 erkannten Objekten, wobei es sich bei fünf um Cookies handelte jedoch ein Registrykey und ein Registryvalue enthalten waren. Ein weiterer Versuch an einem Debian Woody 3.0 Server mit Apache 2 Webserver und

² Vgl. Cert, Zugriff am 27.3.2006

³ SANS, Zugriff am 27.3.2006

Reinhard Hofer 4

Sicherheitsanalyse Webserver

öffentlicher statischer IP zeigte durch Analyse der Serverprotokolle etwa einen Angriff pro Sekunde, wobei unter Angriff auch Portscans gewertet wurden. Die Firewall auf dem Rechner, auf dem dieses Dokument erstellt wurde, zeigt vom Zeitpunkt der Installation des Systems, dem 3.6.2005 bis zum 27.3.2006 insgesamt 483.648 Vorfälle, wobei davon 53.537 als kritisch angesehen werden. Dies ergibt etwa einen Angriff pro Sekunde, wobei man noch hinzurechnen muss, dass der Rechner nur geschätzt etwa ein Viertel der Zeit wirklich online war. Die verwendeten Firewalls waren Zonealarm 5 und 6.

Es gibt eine ganze Reihe an Gefahren für ein Netzwerk bzw. Server, von Naturgewalten beginnend über Angriffe bis hin zu fehlerhaftem Code. Für die meisten Szenarien gibt es Schutzmechanismen und Vorgehensweisen, jedoch kann das sicherste System keinen Fehler im Sourcecode verhindern. Selbst die beste Firewall und der sicherste Webserver können nicht verhindern, dass Unbefugte Zugriff auf geschützte Seiteninhalte haben, wenn das Passwort im Sourcecode steht oder noch schlimmer, auf einem Zettel unter der Tastatur klebt. Laut den Microsoft Certified System Engineer - Unterlagen ist der erste Schritt für ein sicheres System das Abschließen des Serverraums. Tatsächlich kann man jemand Unbefugten, der physischen Zugriff auf einen Server hat, nicht mehr aufhalten. Mittels Software zum Cracken von Passworten kann man einen Windows Client innerhalb von Augenblicken mittels einer entsprechend präparierten Diskette knacken, wobei der Vorgang bei einem Domaincontroller etwa 30 Minuten dauert, da man hier auch die Registry bearbeiten muss. Ein im Zuge dieser Arbeit entsprechend durchgeführter Versuch an einem Windows XP Client und zusätzlich an einem Windows 2000 Server als Domaincontroller hat Erfolg gezeigt, wobei damit im Detail das Zurücksetzen des lokalen Administratorkontopassworts gemeint ist. Die entsprechende Diskette zum Booten des Systems wurde mit der Software Offline NT Password & Registry Editor erstellt. Durch das Zurücksetzen des Passworts auf leeren Inhalt, ist danach das Einloggen als lokaler Administrator ohne Passwort möglich, was bei einem Domaincontroller den Zugriff auf die ganze Domäne inklusive aller Clientrechner bedeutet. Zugegebenermaßen hinterlässt man Spuren, da einerseits das Passwort nicht mehr gesetzt ist, was beim ersten Einloggen des Zuständigen bemerkt wird, zweitens wird das Herunterfahren des

Reinhard Hofer 5

Sicherheitsanalyse Webserver

Systems für den Boot mit der Diskette protokolliert bzw. ab Windows Server 2003 beim Neustart darauf hingewiesen. Die noch einfachere Variante wäre, die Festplatte auszubauen und an einem eigenen Rechner mit Administratorrechten einzubauen und im Betriebssystem den Besitz über die gesamte Verzeichnisstruktur zu übernehmen. Dadurch erreicht man zwar keinen Zugriff auf das komplette Netzwerk, jedoch auf die auf der Platte gespeicherten Daten inklusive eventuell vorhandener Passworten.

2.2 Passwortgeschützter Zugang

2.2.1 HTML und clientseitige Skripte

Die Hypertext Markup Language an sich birgt kein Risiko, da HTML eine Auszeichnungssprache ist und keine aktiven Inhalte hat. Clientseitige Skripte werden jedoch in HTML eingebunden. Aktive Inhalte können bösartigen Code enthalten, der ein entsprechendes Sicherheitsrisiko darstellen kann. Aktive Inhalte können Dynamic HTML, VB-Script oder JavaScript sein. Clientseitige Technologien sind die etwas einfachere Lösung, da man keinen Webserver benötigt, der den Code interpretiert, jedoch sind serverseitige Technologien state of the art und mächtiger. Java-Applets werden oft von Banken für Onlinebanking verwendet. Java-Applets stellen Javacode dar, der von einer virtuellen Javamaschine interpretiert wird. Es gibt Sicherheitsmechanismen bzw. das Sandkastensystem, das einem Applet Einschränkung auferlegt, so dass das Ändern von Systemdateien nicht möglich ist. Der Sandkasten ist eine eigene Laufzeitumgebung. Die einzig relevante Gefahr von Java-Applets ist eine komplette Auslastung der Ressourcen eines Rechners und auch dies ist nicht wesentlich. Applets wurden mit der Idee eingeführt, aktive Inhalte für Webseiten zu bieten, ohne einen ständigen Datentransfer mit dem Server zu benötigen. Servlets sind in etwa das serverseitige Gegenstück. ⁴ Die Konfigurationsoptionen der gängigen Browser erlauben das Deaktivieren von Java.

⁴ Vgl. Krüger (2002), S. 887

Reinhard Hofer 6

Sicherheitsanalyse Webserver

JavaScript ist der wohl bekannteste Vertreter der clientseitigen Skriptsprachen und hat nichts mit der Programmiersprache Java zu tun. Die gängigsten Anwendungsgebiete sind Formulare und Popups. Man kann sogar programmieren, dass beim Schließen eines Fensters ein neues oder eine Vielzahl geöffnet wird. Das ist jedoch nicht das wesentliche Sicherheitsrisiko. Erheblicher sind Angriffe, die Sicherheitslücken von Browsern ausnutzen. Skripte können in den gängigen Browsern deaktiviert werden. JavaScript beinhaltet jedoch

Sicherheitsmechanismen wie die Überprüfung der Herkunft eines Skripts und Signed Scripts. JavaScript kann nur auf Webseiten der gleichen Quelle unbeschränkt zugreifen. Dadurch wird verhindert, dass mit JavaScript Daten eines anderen offenen Browserfensters ausgelesen werden. Mit gleicher Quelle ist der Domainname gemeint, wobei weder ein anderes Protokoll (ftp:// statt http://) noch ein anderer Port vorkommen darf. Signed Scripts dienen zur Erweiterung bzw. Aufhebung ehemaliger Beschränkungen. Dadurch ist es nun möglich, Dateien am Client zu lesen oder zu ändern, Fenster ohne Rahmen zu erzeugen, die vor allem für Popups geeignet sind, Emails zu versenden usw. Zur Erzeugung von Signed Scripts benötigt man ein Zertifikat, welches angekauft werden muss. Es herrscht jedoch ein großer Preisunterschied bei privaten und kommerziellen Zertifikaten. Einige Browser erlauben es, das obligatorische Einbinden eines Zertifikates zu deaktivieren. Ein Zertifikat informiert über den Ersteller eines Programms und soll bei der Entscheidung helfen, ob man den Inhalten einer Seite oder eines Programms vertraut und diese nutzt. Das Zertifikat, ausgestellt von einer Certificate Authority, garantiert die Identität einer Person oder Firma und stellt eine digitale Unterschrift dar, die auf Verschlüsselung basiert. Weiters garantiert ein Zertifikat, dass die Codeinhalte seit dem Erstellen bzw. dem Release nicht verändert wurden. JavaScript an sich kann in gängigen Browsern deaktiviert werden. 5

2.2.2 Serverseitige Skripte

Serverseitige Skripte stellen Code dar, der am Webserver ausgeführt wird und wo nur das Ergebnis an den Client gesendet wird. Dadurch eignen sich diese besser

⁵ Vgl. Koch (2001), S. 407

Reinhard Hofer 7

Sicherheitsanalyse Webserver

für sensible Anwendungsgebiete als clientseitiger Code. Die bekanntesten Vertreter dieser Technologie sind Active Server Pages, Java Server Pages, PHP und Perl. ASP benötigt den Internet Information Server und ist eine Microsofttechnologie, deren letzte Version ASP.NET darstellt. ASP benötigt im Gegensatz zu den folgenden Sprachen keine eigene Installation zusätzlicher Komponenten, vom obligatorischen Webserver abgesehen. JSP basiert auf Javacode und benötigt Tomcat als Servletengine. Tomcat stellt die Umgebung zum Ausführen des Javacodes auf dem Webserver dar, womit JSP eine Softwarekomponente mehr benötigt. PHP basiert von der Syntax auf C und obwohl C nicht objektorientiert ist, bietet PHP diese Möglichkeit. PHP muss auf dem System installiert sein, um vom Webserver ausgeführt werden zu können, genau wie es bei Perl der Fall ist. Perl hat den Ruf einfach und doch mächtig zu sein.

Jede Sprache hat ihre Vor- und Nachteile, wobei der Webserver bei serverseitigen Skripten zur Ausführung obligatorisch ist, was bei clientseitigen Technologien nicht der Fall ist. Die Sicherheitsproblematiken sind grundsätzlich ähnlich.

2.2.3 Referer Header und Cookies

Internetbenutzer sind meist der Überzeugung, sich in einer gewissen Anonymität zu bewegen. Vom gesetzlichen Standpunkt trifft dies auch zu, da in Österreich das Datenschutzrecht sehr streng ist. Wirklich anonym ist man jedoch nie, außer man benutzt öffentliche Hot Spots für WLAN. Es ist ohnehin eine gute Idee, sich für Webseiten, die eine Registrierung verlangen, eine zweite Identität zuzulegen oder so genannte Anonymizerprogramme zu verwenden. Dies ist vor allem eine Maßnahme, um sich vor Spam und Weitergabe privater Daten wie Serverhalten zu schützen. Bei sicherheitskritischen Seiten wie Telebanking muss man die eigene Identität ohnehin nachweisen. Genauso gilt dies beim Abschluss von online Verträgen. Dabei ist man ebenfalls zur wahrheitsgemäßen Angabe verpflichtet. Anonymität hat aber auch hier ihre Grenzen. Zumindest der eigene Internetprovider weiß, wer seine Benutzer sind. Bei analogem Zugang wird man durch die Telefonnummer identifiziert und bei sonstigen wie Kabel, Satellit usw. durch die IP-Adresse. Alle Verbindungen laufen über den Internetprovider und

Reinhard Hofer 8

Sicherheitsanalyse Webserver

werden meist auch protokolliert. Diese persönlichen und somit sensiblen Daten dürfen natürlich nicht einfach weitergegeben werden. Der Provider selbst kann aber bei Vorliegen von entsprechenden Gründen zur Herausgabe der Daten verpflichtet werden. Solche Gründe können beispielsweise gesetzliche Ermächtigung bei Strafverfolgung oder Gerichtsverhandlungen sein. 6

Nicht nur der Internetprovider hat ein Interesse daran, wer seine Dienste benutzt. Der Betreiber des Servers, mit dem man sich verbindet, kann ebenso ein Interesse daran haben, wer auf seine Informationen zugreift. Der Webserverbetreiber hat es bereits etwas schwieriger, da dieser weniger Daten zur Verfügung hat. Natürlich sieht man auch am Ziel, welche IP-Adressen gerade zugreifen bzw. im Webserverprotokoll, wer worauf zugegriffen hat. Weniger hilfreich ist dies, wenn mit einer dynamisch vergebenen IP-Adresse zugegriffen wird, da derselbe Benutzer mit unterschiedlichen IP-Adressen auf die Webserverressourcen zugreift. Dieses Problem kann man mit Cookies umgehen. Wenn man auf Webressourcen zugreift, kann der Server zusätzlich Cookies senden. Cookies sind Textdateien. In Windows XP werden diese beim Benutzer auf der Systempartition unter \Documents and Settings\Benutzername\Cookies abgelegt. 7

Abbildung 2.1: Beispielcookie von www.amazon.de

Diese Textdatei wird ab diesem Zeitpunkt bei jeder Anfrage an den Webserver geschickt. Durch diese Methode kann der Webserver alle Zugriffe eines Benutzers miteinander in Beziehung bringen. Prinzipiell kann dadurch aber nur der betreffende Zielserver das Surfverhalten mitprotokollieren bzw. auswerten. Das liegt daran, dass Cookies nur dann verwendet werden können, wenn sich der Benutzerrechner und der Webserver in derselben Netzwerkdomäne befinden. Somit kann der Webserver der Webseite mit der URL www.seite1.at nicht Cookies

⁶ Vgl. Arbeiterkammer, Zugriff am 21.3.2006 bzw. Bundesministerium für Inneres, Zugriff am 21.3.2006

⁷ In der englischen Version von Windows.

Reinhard Hofer 9

Sicherheitsanalyse Webserver

der Webseite mit der URL www.seite2.at auslesen. Zusätzlich zu den abgerufenen Seiten wird durch den Browser auch mitgeteilt, wenn der Benutzer über den Link einer anderen Webseite kam. Diese Angabe wird Referer-Header bezeichnet. Durch die Verbindung von Cookie und Referer-Header und dem daraus entstandenem Wissen, welcher Benutzer welche Seiten betrachtet, ist es möglich, Benutzern gezielt Werbung anzuzeigen. Letztendlich laufen diese Maßnahmen auf den gläsernen Kunden hinaus. ⁸ Vor allem Internetwerbefirmen nutzen diese Information, da Werbebanner auf verschiedenen Seiten von einer Werbefirma betreut werden. Diese Firma ist somit nicht nur in der Lage, Kundenpräferenzen einer einzelnen Domäne zu kennen, sondern von allen Domänen auf denen Anzeigen der Firma platziert sind.

Abgesehen von der Datenschutzproblematik können Cookies für Passworte oder für automatische Anmeldung verwendet werden. Da Cookies meist nicht verschlüsselt übertragen werden, sind diese anfällig für Sniffing. Es gibt mehrere Möglichkeiten für Benutzer Cookies auszuschalten. Einerseits können diese im Browser deaktiviert werden oder nur bestimmten Domänen erlaubt werden, Cookies zu setzten. Man kann auch das ganze Cookieverzeichnis sperren und einen Schreibschutz im Betriebssystem setzen.

2.2.4 Codebeispiele

2.2.4.1 Beispiel 1 - Sourcecodeanalyse

Es gibt unterschiedliche Methoden, um den Zugang auf eine Seite zu regeln. Je nach Möglichkeit kann man einfache oder komplexe Methoden einsetzen. Die technisch einfachste ist ein Passwortvergleich mittels JavaScript direkt im HTML-File. Im folgenden Beispiel gibt es nur einen Benutzer und Passwort, da die Prozedur für jeden weiteren Benutzer gleich ist.

⁸ Vgl. Lessig (2003), S. 53 Reinhard Hofer 10

Sicherheitsanalyse Webserver

Listing 1: HTML-Seite mit Aufruf der JavaScriptdatei.

Listing 2: JavaScriptfunktion zur Passwortabfrage.

In Listing 1 wird die Funktion zur Passwortabfrage in einer separaten JavaScript-Datei gespeichert. Das ist nicht zwingen notwendig, da der JavaScriptsource auch direkt in der HTML-Datei stehen kann. Das Einzige, was ein Betrachter dieser Seite tun muss, ist, sich den Sourcecode anzeigen zu lassen, was gängige Browser erlauben. Darin steht klar und deutlich das Passwort. Das separate Speichern der Funktion erhöht die Sicherheit nur minimal, da man den Inhalt der Datei passwort.js ebenfalls im Browser darstellen lassen kann. Internetexplorer ab Version 6 zeigt bei direkter Eingabe der JavaScript-Datei nicht deren Inhalt an, alle vorhergehenden Versionen sowie Mozilla aber sehr wohl. Den Namen der Funktionsdatei erhält man leicht durch den Inhalt der HTML-Datei. Jeder Angreifer wird zuerst den Source betrachten, um zu wissen, welche Technik des Passwortschutzes gewählt wurde. Selbst das Speichern des Passworts in einer separaten Datei, damit dieses nicht direkt im Source steht, nützt nichts, wenn diese Passwortdatei nicht verschlüsselt ist.

Selbst wenn dieser einfache Mechanismus funktioniert und jemand das Passwort nicht herausbekommt, bleibt immer noch der Versuch, einfach eine Seite dahinter aufzurufen. Man benötigt oft nur eine einzelne Seite dahinter bzw. deren URL, um

Reinhard Hofer 11

Sicherheitsanalyse Webserver

auf alle Inhalte hierarchisch darunter stehend zuzugreifen. Viele Seiten sind nach dem gleichen Schema aufgebaut und beginnen mit der Startdatei index.htm(l). Manche Webspaceserver fordern diese Datei aus organisatorischen Gründen. Unterseiten können natürlich alle möglichen Namen haben, jedoch sind main.htm, left.htm, frame.htm, seite1.htm usw. nahe liegende Versuche. Einerseits wählen die Ersteller von Webseiten einfache und eindeutige Namen, um den Erstellprozess der ganzen Webseite zu vereinfachen, zusätzlich schlagen diverse HTML-Editoren wie Frontpage zum Beispiel beim Erstellen von Frameseiten solche Dateinamen vor. Selbst wenn man keinen einzigen Treffer errät, geben Suchmaschinen oft Hinweise auf Unterseiten bei der Ausgabe der Trefferliste, da deren Robots das Internet durchforsten und gefundene Seiten indexieren. Oftmals werden Formulare verwendet, die eine Aktion aufrufen, in der mitgeteilt wird, was beim Klicken des Formulars erfolgen soll. Steht hier im Attribut action das Ziel, kann man die Unterseite auch direkt aufrufen. Auch wenn hier kein Erfolg beschert ist, gibt es immer noch die Möglichkeit, statt einer einzelnen Seite einfach das Verzeichnis aufzurufen. Dazu lässt man in der Adressleiste des Browsers die Seite selbst weg. Wurde im Webserver konfiguriert, dass das Auflisten von Verzeichnisinhalten möglich ist, werden daraufhin alle Dateien des Webserververzeichnisses angezeigt, die man daraufhin auch einzeln aufrufen kann. Ist diese Option aktiviert, hilft auch nicht, dass die aktive Funktion der Passwortabfrage am Webserver durchgeführt wird. Verzeichnisinhalte auflisten deaktivieren reicht jedoch nicht aus als Schutz gegen Webcrawlern, die komplette Homepages runterladen. Dazu muss man nur die Starturl einer Homepage kennen, die ja kein Geheimnis ist und den Download beginnen. Der Webcrawler lädt dann alle Seiten inklusive der Verzeichnisstruktur in ein lokales Verzeichnis. Manche Programme erlauben auch den Download bestimmter Dateitypen wie JPEG oder AVI usw. Um Webcrawler fernzuhalten, benötigt man entweder entsprechend aufgebauten Code wo Seiten prüfen, ob man authentifiziert ist bzw. Berechtigung hat oder man konfiguriert das Webverzeichnis mit entsprechenden Berechtigungen bzw. setzt Sessions ein.

Schwachstellen:

Reinhard Hofer 12

  Sicherheitsanalyse Webserver  

  Sourcecode gibt Hinweise  

  Unterseiten und Dateien sind nicht geschützt bzw. von Suchmaschinen  

  indexierbar  

  Webcrawler haben Zugriff  

  Verzeichnisinhalte auflisten möglich  

2.2.4.2  Beispiel 2 Sourcefehler  

  Die Passwortabfrage kann auch serverseitig erfolgen. Bei serverseitigen  

  Skriptsprachen sieht man nur das Ergebnis und nicht den Code dahinter. Genau so  

  kann das Passwort in einer Datei gespeichert werden. Oft ist es nicht nötig, das  

  Passwort selbst zu wissen, um an die Inhalte zu kommen. Gesetz dem Fall die  

  aufgerufene Seite findet die Passwortdatei nicht, dann vergleicht die  

  Passwortabfrage die Eingabe mit Nichts. Ist das Eingabefeld leer, so würde die  

  Funktion zur Passwortabfrage true zurückgeben und den Zugriff gewähren. Der  

  erste Schritt beim Testen, ob ein passwortgeschützter Zugang sicher ist, ist die  

  Eingabe eines leeren Passworts  

  Der Sourcecode einer Datei an sich ist möglicherweise korrekt, jedoch können  

  Angreifer diesen nicht nur einsehen, sondern auch kopieren und eigene Dateien  

  damit erstellen. In diesen lokalen Dateien kann der Inhalt dementsprechend  

  geändert werden. Dies kann dazu benutzt werden um eigene Werte  

  zurückzugeben. Weiters gibt es auf beinah jeder Seite mit Passwortzugang die  

  Möglichkeit, sich ein Passwort an die eigene Emailadresse senden zu lassen  

  Professionell wird das Versenden von Emails mittels einem serverseitigen Skripts  

  erledigt, jedoch sieht auch reines HTML diese Möglichkeit vor. Besonders in  

  diesem Fall ist es ein Leichtes, die eingetragene Emailadresse einfach auf die  

  eigene zu ändern, um sich das Passwort einfach zusenden zu lassen. Man sieht  

  recht deutlich, je einfacher die verwendete Technik umso unsicherer das Ergebnis  

  Formulare sind generell mit Vorsicht zu genießen. Zwar erlauben serverseitige  

  Skripte die Auswertung des Formularinhalts am Server womit der Sourcecode  

  dieses Vorgangs dem Benutzer verborgen bleibt, jedoch werden diese  

  Formulardaten letztendlich auch irgendwie übermittelt. In HTML gibt es die  

  Möglichkeit bei Eingabefeldern den Typ mit password zu definieren. Dadurch sieht  

  man bei der Eingabe nur Jeder HTML-Formular hat jedoch im Element  

  Reinhard Hofer  13

Sicherheitsanalyse Webserver

Sicherheitsanalyse Webserver

Adressleiste anhängen bzw. ändern. Hat man jetzt in einem Skript programmiert, dass bei korrekter Eingabe des Benutzernamens und des Passworts die Variable authorisation auf true, also korrekt, gesetzt wird und man danach weitergeleitet wird, so können Angreifer einfach dies Variable inklusive des Wertes true in der Adresszeile anhängen und es wird dem Skript am Server übergeben. Die Eingaben an sich mögen zwar falsch sein, der Wert der Variable die dies entscheidet sagt aber aus, dass die Eingabe korrekt ist. Die Abhilfe ist recht simpel, man setzt einfach im Skript, das von der Formularseite aufgerufen wird, den Wert der Variable authorisation standardmäßig zu Beginn auf false. Wird jetzt von der Passworteingabeseite die Variable authorisation mit true übergeben, dann wird diese sofort beim Ausführen des Skripts auf false gesetzt, danach die Benutzereingaben überprüft und bei Korrektheit wieder auf true gesetzt. Der entscheidende Punkt ist jedoch, dass bei falscher Eingabe der Wert der Variable false bleibt und der Code danach, der die Seite dahinter aufruft, nicht ausgeführt wird. 9

Listing 4: PHP-Passwortabfrage. Die Codeinhalte bekommt der Benutzer nicht zu sehen, sondern sieht bei falscher Eingabe ein Formular mit zwei Eingabefeldern oder eben den Text „Korrekte Eingabe!“. Dieses Skript funktioniert aber nur bei aktiviertem register_globals.

⁹ Vgl. Yank (2003), S. 200

Reinhard Hofer 15

Sicherheitsanalyse Webserver

Schwachstellen:

• Leeres Passwort funktioniert.

• Sourcecode kann lokal geändert werden.

• Formularmethode get.

• Übergebene Variablen veränderbar. 2.2.4.3 Beispiel 3 - Sessions

Um zu verhindern, dass Benutzer einfach Unterseiten direkt aufrufen, kann man Sessions verwenden. Jeder authentifizierte Benutzer baut eine eigene Session auf und in dieser wird festgehalten, dass sich der Benutzer authentifiziert hat. Sessionvariablen können aber ebenfalls über Benutzereingaben modifiziert werden. Das kann wiederum ausgenutzt werden, um die Sessionvariable einfach auf true zu setzen. Eine Lösung des Problems ist register_globals abschalten, wodurch globale Variablen nicht mehr gelten. Dann funktioniert das Skript aber an sich nicht mehr. Deswegen speichert man die Sessiondaten in Arrays.

Listing 5: PHP-Passwortabfrage. Funktioniert mit abgeschaltetem register_globals.

2.2.4.4 Beispiel 4 - Skriptinjections & Referer & Cookies Referer dienen dazu, einem Server mitzuteilen, woher der Besucher kommt. Um zu verhindern, dass Besucher einfach die Seiten unter der Passwortabfrage aufrufen, kann man prüfen, ob diese Besucher auch vorher die Seite mit der Passwortabfrage aufgerufen haben und von dieser weitergeleitet wurden. Nur

Reinhard Hofer 16